Security & engineering practices

Authentication

We use established identity providers and standard protocols rather than building custom login systems from scratch. On Microsoft-first projects that typically means Azure Entra ID (formerly Azure AD). Where clients already use another provider, we integrate with what you run.

Multi-factor authentication is supported where the identity provider allows it. Session handling, token expiry, and logout behaviour are defined in the architecture, not added late in the project.

Role-based access control

Permissions are defined by role, not hard-coded per user. We map roles to what each person actually needs to do in the system, and review those mappings during design.

On multi-user platforms like GIP and Stokha, access is enforced at the API and data layer, not only in the user interface.

Audit logs

We log meaningful actions: who accessed what, when data changed, and when sensitive operations ran. Logs are structured so they can be reviewed during an incident or compliance conversation.

What gets logged depends on the system. We define that during architecture, based on your risk profile, not as a checkbox before go-live.

Tenant isolation

On multi-tenant systems, each customer’s data is isolated at the database or storage layer. We do not rely on application-level filtering alone.

Tenant boundaries, shared resources, and cross-tenant admin access are documented in the architecture blueprint before build.

Secure development

Security is part of design, not a final phase. That includes:

• Reviewing architecture for common risks before coding starts
• Keeping dependencies updated and scanning for known vulnerabilities
• Storing secrets in proper vaults, not in source code or config files
• Using HTTPS everywhere data moves over the network
• Validating input at system boundaries
• Separating development, staging, and production environments

We do not claim a formal certification we have not earned. We can walk through our practices in a due diligence call.

Backups and recovery

Production systems include automated backups with a defined retention period. Recovery steps are documented so they can be tested, not guessed during an outage.

Backup frequency and recovery targets depend on the system. We agree those with you during design, based on how much downtime or data loss the business can tolerate.

AI governance

On AI systems like GIP, we treat governance as part of the product, not an upsell:

• Answers cite sources so users can verify them
• Access controls apply to documents and data used by the model
• Prompts and responses can be logged where accountability matters
• Human review stays in the loop for high-stakes decisions
• Client data used for one engagement is not reused for another without agreement

We do not train on your confidential data unless you explicitly ask us to, and we document how models and embeddings are stored.

What we do not claim

We are a software company, not a certified auditor. We build systems with security built in from day one. If you need ISO 27001, SOC 2, or sector-specific compliance, tell us early and we will design for those requirements or point you to specialists where we are not the right fit.

Security contact

For security-related questions during a live engagement, or to raise a responsible disclosure privately, contact hello@gargisolutions.in.