- Documented scope, roles and acceptance criteria
- Mutual NDA and IP terms where agreed
- Threat-model and sensitive-data review
- Named access, audit events and release evidence
VERIFIABLE TRUST
Security claims should survive technical scrutiny.
This page states what we practice, what can be contractually defined, and what we are not currently certified to claim.
CURRENT STATUS
Transparent about maturity, serious about controls.
Dharmarth is not currently SOC 2 or ISO 27001 certified. We will not use “enterprise-grade” as a substitute for evidence. Engagement-specific requirements are reviewed before access to client systems or sensitive data.
- SOC 2 certification
- ISO 27001 certification
- Guaranteed absence of vulnerabilities
- Automatic permission to process regulated data
CONTROL AREAS
Security integrated with delivery.
Controls are selected in proportion to system risk. The list below describes the current application and delivery baseline, not a universal certification.
Application security
- Server-side schema validation at public trust boundaries
- Same-origin and CSRF controls for sensitive browser actions
- Rate limiting for authentication, lead and checkout endpoints
- Argon2 password hashing and optional TOTP MFA
- Role and session checks on administrative routes
Data handling
- Data minimization in public qualification flows
- No collection of card data by Dharmarth application servers
- Environment-based secrets; no credentials committed to source
- Audit events for security-sensitive and commercial actions
- Explicit sensitive-data review during scoping
Delivery controls
- Automated build and validation before release
- Staging and approval gates for production-changing work
- Dependency review and security-header baseline
- Documented rollback and operational ownership
- Browser verification for critical customer journeys
AI systems
- Defined evaluation cases and failure criteria
- Human-review gates for consequential actions
- Traceability of model-assisted behavior where required
- Model and provider assumptions recorded as architecture decisions
- No claim that probabilistic behavior is perfectly safe
ENGAGEMENT ACCESS MODEL
Least privilege from kickoff to handover.
- 01Before access
Classify the work
Identify sensitive data, regulated workflows, environments, integrations and consequential actions.
- 02Written scope
Define boundaries
Agree repositories, accounts, roles, secrets, retention and prohibited data in the SOW or security plan.
- 03During delivery
Operate visibly
Use named access, reviewable changes, decision records and client-controlled production approvals.
- 04Closeout
Revoke and hand over
Remove access, transfer relevant artifacts and confirm remaining retention obligations.
SECURITY FAQ
Direct procurement answers.
Are you SOC 2 or ISO 27001 certified?
No. Dharmarth does not currently claim either certification. We disclose that early so procurement teams can evaluate the engagement honestly.
Can you sign an NDA or DPA?
Mutual NDA, IP assignment and data-processing terms can be included where applicable, subject to review and agreement by both parties.
Will you work inside our cloud and repositories?
Yes when that is the safest operating model. Access should be least-privileged, named, revocable and scoped to the engagement.
Do you retain client source code or customer data?
Retention is defined in the engagement and data-handling plan. Client systems should remain under client ownership, and unnecessary copies should not be created.
Send the security requirements early.
The safest time to discover a procurement or data-handling constraint is before the proposal.