Security and data privacy.

This page describes what Inkwelly actually does today, in plain language, so that your IT reviewer can check it rather than take it on trust. Where something is not in place yet, it says so.

Where your data lives

Your school's data is stored in Mumbai, India. The application, the database and the cache run on servers in Mumbai; uploaded files — photos, documents, generated PDFs — are held in Amazon S3 in the same Mumbai region. Nothing is stored outside India.

Traffic reaches those servers through Cloudflare, which terminates TLS and filters malicious requests before they arrive. That matters for schools subject to the Digital Personal Data Protection Act, 2023, and for international schools whose parents ask where records are kept.

Encryption and access

• In transit: TLS 1.2 or higher on every request, with modern ciphers only. There is no unencrypted path into the platform.
• Card data: never touches Inkwelly servers. Online fee payments are handled entirely by the payment gateway's PCI-DSS-compliant systems.
• Database access: the database is not reachable from the public internet. It accepts connections only from the application on the same private host.
• Server access: administrative access is firewalled, with automatic blocking of repeated failed sign-in attempts.

Backups

The full database is backed up automatically every night, and again immediately before every release — so there is always a restore point from just before any change reaches your school. Backups are retained on a rolling schedule, and the hosting platform keeps its own periodic snapshot of the whole server.

We restore from these in practice, not just in theory: when a release once removed a set of report cards, they were restored from the pre-release backup with every mark, verification code and certificate number intact.

Multi-tenant isolation

Every school is a distinct tenant. Data access is enforced at the database query level on every single request — there is no shared-state path that would let one school's data appear in another school's queries. Engineering reviews specifically check tenant-isolation correctness on every change.

Role-based access control

Every user has a role — principal, administrator, teacher, accountant, parent, student, driver — carrying granular permissions. A teacher cannot see fees. An accountant cannot open marks entry. A parent sees only their own child. Permissions are enforced on the server, not merely hidden in the interface, and a school can narrow them further per person.

Authentication

• Phone and email sign-in with a one-time code by SMS or WhatsApp — there is no reusable password for a parent or teacher to have stolen.
• Sign-in with Google, Microsoft or Apple for staff.
• Short-lived session tokens, renewed by secure rotation.
• Every user can see their own signed-in devices, sign out any of them, and review a login history. An administrator with the right permission can do the same for any account in the school.

Compliance and alignment

• DPDP Act 2023: aligned with Indian data-protection requirements — lawful basis, purpose limitation, data minimisation and the rights below.
• Children's data: processed under the school's institutional authorisation and the parental consent taken at enrolment. The school is the data fiduciary; Inkwelly is its processor.
• Data processing agreement: available on request, naming every provider below.

Who else touches your data

No school should have to guess at this. These are the providers involved in running Inkwelly, and what each one does:

• Amazon Web Services (Mumbai): storage for uploaded files and generated documents.
• Cloudflare: TLS termination, caching of public pages, and filtering of malicious traffic.
• Payment gateways (Razorpay, PayU and similar, as your school chooses): online fee collection and settlement.
• Meta WhatsApp Business API: delivery of WhatsApp messages to parents.
• SMS gateway: delivery of text messages and one-time codes.
• Google Firebase: delivery of mobile app notifications.
• Amazon Rekognition (Mumbai): only if your school switches on face-verified staff check-in. It is off by default.

Operational security

• Structured logging with a correlation ID on every request.
• Audit trails for administrative actions — who changed what, and when — readable by the school, not just by us.
• A health check on the API with automatic recovery if it stops responding.
• Sensitive exports are permission-gated separately, including the ones the AI assistant can produce.

What we have not done yet

We have not commissioned a third-party penetration test. If your school or your board requires one before signing, we will support a review under an agreed scope and share what it finds. We would rather tell you this than let you assume otherwise and discover it during procurement.

Your rights

As a school (data fiduciary) and as a parent, student or employee (data principal), you have the right to:

• Access the personal data we process about you.
• Correct inaccurate data.
• Request deletion, subject to legal retention requirements and school policy.
• Export data in standard, machine-readable formats — every module has its own CSV, Excel or PDF export.
• Withdraw consent where processing relies on consent.

Email [email protected]with the subject "Data Request" and we'll respond within 3-5 business days.

Incident response

If we detect a security incident, we will notify affected schools within 72 hours with a summary of what happened, what data was affected, what we did about it, and what you should do. We believe in transparency over reputation management.

Questions or concerns

Security is not a set-and-forget topic. If you have a question, a concern, or you want a security review before signing a pilot agreement, email [email protected] or WhatsApp +91 9203510698.