Data Security Policy

1. Scope

This Policy covers all Customer Data and personal data processed by the Service, across our production application, databases, backups, and supporting systems, and applies to all Namith personnel and contractors with access to those systems.

2. Governance and Responsibility

2.1. Overall accountability for information security rests with [designation — e.g., the Director responsible for Technology]. Security responsibilities are assigned in writing to specific personnel.

2.2. All personnel with access to production systems or Customer Data are bound by written confidentiality obligations and receive security awareness training at induction and at least annually thereafter.

2.3. Security policies, access lists, and this document are reviewed at least annually and upon any material change to our architecture or applicable law.

3. Data Classification

4. Infrastructure and Hosting

4.1. The Service is hosted with [cloud provider] in data centres located in [India — specify region]. The provider maintains industry-standard physical security and holds certifications including [ISO 27001 / SOC 2 — per provider].

4.2. Production, staging, and development environments are segregated. Customer Data is not used in development or testing environments; where realistic data is needed, it is synthetic or irreversibly anonymised.

4.3. Production networks are isolated behind firewalls and security groups configured on a default-deny basis. Databases are not directly reachable from the public internet.

5. Encryption

5.1. In transit: all connections to the Service — web, mobile, and API — are encrypted using TLS [1.2+]. Plain HTTP is not served; HSTS is enforced.

5.2. At rest: databases, file storage (including uploaded attachments and logos), and backups are encrypted using industry-standard algorithms (AES-256 or equivalent) with keys managed through the cloud provider's key management service.

5.3. Encryption keys are rotated per [provider-managed rotation / defined schedule], and access to key management is restricted and logged.

6. Access Control

Your side — controls you operate

6.1. OTP-gated authentication. Every login to LedgrBook — web and mobile, without exception — is verified by a one-time password to the user's registered mobile number. There are no shared passwords to leak.

6.2. Role-based permissions. Access within your Organisation is governed by the roles and permissions you assign — down to per-subject rights (view, create, edit, void, export) and sensitive-data flags such as purchase-price visibility. These permissions are enforced at the server, not merely hidden in the interface.

6.3. Session controls. Sessions expire after inactivity; tokens are invalidated on logout and on access revocation. When you disable a user, their access ends across every company in your Business Group.

6.4. Audit trail. Financial actions in the Service are attributable: documents record who created, edited, and voided them, and voids require reasons. Nothing in finalized books is silently deleted.

Our side — controls we operate

6.5. Least privilege. Namith personnel access to production systems is granted on a need-to-use basis, individually identified (no shared administrative accounts), protected by multi-factor authentication, and reviewed at least quarterly. Access is revoked on the day a person's role ends.

6.6. Support access. Our support staff do not have standing access to your business records. Where diagnosing an issue requires accessing your Organisation's data, access is [granted with your permission / logged and time-limited], and is recorded.

6.7. All administrative access to production is logged, and logs are protected against tampering.

7. Application Security

7.1. The Service is developed against recognised secure-coding standards (including the OWASP Top 10), with protections covering injection, cross-site scripting, cross-site request forgery, broken access control, and insecure direct object references.

7.2. Tenant isolation. LedgrBook is a multi-tenant service; every query and API operation is scoped to the requesting user's Organisation and permissions. Cross-tenant access is prevented at the application and data layers and covered by automated tests.

7.3. Code changes are peer-reviewed before deployment; dependencies are monitored for known vulnerabilities and patched on a defined cadence — critical vulnerabilities within [72 hours] of a fix becoming available.

7.4. We conduct periodic vulnerability assessments, and [annual] penetration testing by [an independent third party / qualified internal team]. Material findings are remediated on a risk-prioritised schedule.

7.5. Rate limiting, input validation, and abuse detection protect authentication endpoints, including OTP request throttling to prevent SMS abuse.

8. Backups and Business Continuity

8.1. Production databases are backed up [daily], with point-in-time recovery enabled for a rolling window of [7–35] days. Backups are encrypted and stored in a separate location/availability zone from the primary systems.

8.2. Backup restoration is tested periodically ([quarterly]) — a backup that has never been restored is a hope, not a safeguard.

8.3. Recovery objectives: Recovery Point Objective (RPO) of [24 hours or better] and Recovery Time Objective (RTO) of [X hours] for a full-region incident. These are engineering targets, not contractual warranties, unless separately agreed.

8.4. Backups exist for disaster recovery, not as an archive service. Data deleted in accordance with our retention rules is also purged from backups on the rolling cycle described in the Privacy Policy.

9. Monitoring, Logging, and Detection

9.1. We maintain centralised logging of application events, authentication attempts, administrative actions, and infrastructure health, with alerting on anomalous patterns (repeated failed OTPs, unusual export volumes, privilege changes).

9.2. Logs are retention-limited (see Privacy Policy), access-controlled, and excluded from containing plaintext OTPs, tokens, or payment data by design.

10. Vendor and Sub-Processor Security

10.1. Third parties that process data for us (hosting, SMS/OTP, email, payments — listed in the Privacy Policy) are assessed before engagement and bound by written contracts imposing confidentiality, security, and instruction-only processing obligations.

10.2. Payment processing is performed entirely by a PCI-DSS-compliant gateway; card and UPI credentials never touch our servers.

10.3. We review the list of sub-processors at least annually and update the Privacy Policy when it changes.

11. Personnel Security

Background verification appropriate to role is performed at hiring [where legally permissible]; confidentiality undertakings are signed before any system access; access is provisioned per role and deprovisioned on exit the same day; and security training is mandatory and refreshed annually.

12. Incident Response and Breach Notification

12.1. We maintain a documented incident response procedure covering identification, containment, eradication, recovery, and post-incident review, with named responders and escalation paths.

12.2. Suspected incidents are triaged immediately; incidents affecting Customer Data are prioritised at the highest severity.

12.3. Notification. In the event of a personal data breach, we will notify the Data Protection Board of India and affected individuals in the form, manner, and timelines prescribed under the Digital Personal Data Protection Act, 2023, and will inform affected business customers without undue delay with sufficient detail to assess impact — what happened, what data was involved, what we have done, and what you should do.

12.4. Every material incident concludes with a written post-incident review and corrective actions, tracked to closure.

12.5. Responsible disclosure. Security researchers who believe they have found a vulnerability are asked to report it to [security@ledgrbook.com]. We commit to acknowledging reports within [72 hours], not pursuing good-faith researchers legally, and crediting reporters who wish it once the issue is fixed.

13. Your Responsibilities

Security is shared. You are responsible for: safeguarding the mobile numbers and devices used for OTP login; assigning roles and permissions appropriate to each team member and revoking access when people leave; the accuracy and lawfulness of data you enter; and promptly reporting suspected unauthorised access to [security@ledgrbook.com]. We are not responsible for access exercised through credentials, devices, or permissions under your control.

14. Certifications and Audits

[State current status honestly — e.g.: "Our cloud infrastructure provider holds ISO 27001 and SOC 2 certifications. Namith's own ISO 27001 certification is planned for [year]; until then, this Policy states the controls we operate and we will answer reasonable security questionnaires from customers."]

15. Changes to This Policy

We may update this Policy as our systems and applicable law evolve. Material changes will be notified by email and/or in-app notice. The "Last updated" date reflects the current version. We will not materially reduce the protections described here without notice.

16. Contact

Security contact: [security@ledgrbook.com]

Grievance Officer: [name], [grievance@ledgrbook.com]

Namith Software Solutions India Private Limited, CIN U62013TZ2023PTC027851, Coimbatore, Tamil Nadu, India