Security & Responsible Disclosure

"DataJewellers" means Data Doodles Tech Private Limited, the operator of the DataJewellers service ("we", "us"). This page sets out the security measures we operate, the part that belongs to each business, and how to report a vulnerability or suspected compromise.

1. What we do

These measures are in place in DataJewellers today, described usefully but without detail that would help an attacker.

• Encrypted transport. Everything is served over HTTPS, with HTTP Strict Transport Security so browsers refuse an unencrypted fallback, and a Content Security Policy that stops pages loading code from anywhere but our own origin. There are no third-party scripts, fonts or tag managers.
• Passwords. Stored only as bcrypt hashes, never in readable form and never in logs, under a length-and-character-mix policy enforced on both client and server.
• Sessions you can revoke. Sessions live in httpOnly, same-site cookies with short lifetimes (12 hours for a workspace, 8 for the operator console). Changing a role, resetting a password or deactivating a user invalidates that user's live sessions immediately instead of waiting for expiry.
• Rate limiting. Sign-in and other sensitive endpoints are throttled by network address and by account.
• Roles and permissions. Every action is checked against a permission catalogue, and businesses can define custom roles, so staff get what their job needs and nothing more.
• Separation between businesses. Each business's records live in their own database schema, selected by workspace hostname — not in shared tables filtered by a customer column.
• MFA for our operators. Platform operator accounts support time-based one-time-password MFA with the secret encrypted at rest, and sensitive actions require step-up re-authentication.
• Support access is visible and bounded. Our staff reach a workspace only through a time-boxed support session that requires a stated reason, is recorded, and is visible to the business in its own audit log.
• Append-only audit logs. Significant actions are recorded with user, time, network address and user agent, and no route edits or deletes an audit entry — on the business side or ours.
• Input validation. Request payloads are validated against schemas before use, and database access is parameterised rather than assembled from strings.
• Encryption at rest. Provided by our hosting provider as a property of its platform. We rely on it; it is not something DataJewellers separately implements or certifies. Operator-run backup files can also be encrypted with an operator-held passphrase.

1.1 What we do not claim

DataJewellers has not undergone a SOC 2 examination or an ISO/IEC 27001 assessment and holds no third-party security certification. We say so plainly rather than imply otherwise, and if that changes we will publish the specifics here. No system is perfectly secure, and we do not claim ours is.

2. The part that belongs to your business

We secure our side; inside a workspace, the business controls who gets in and what they can do:

• Use strong, unique passwords; never share a user account between people.
• Give each role the least it needs, and review who holds administrative roles.
• Deactivate leavers on their last day — it revokes their sessions at once.
• Keep devices locked, updated and signed out on shared counters (see the Mobile & Desktop App Terms).
• Watch your audit log, including for support sessions you did not expect.
• Export your records regularly, so our bad day is never your only copy.

3. Reporting a vulnerability

If you believe you have found a security flaw in DataJewellers, write to support@datadoodlestech.com before telling anyone else, and include:

1. What the issue is and why it is a security problem.
2. The exact hostname, URL or screen involved.
3. The minimum steps needed to reproduce it.
4. What an attacker could achieve with it.
5. Any evidence — request and response details, a short recording, a log excerpt — with real personal data redacted.

We will acknowledge your report within 3 business days, tell you whether we can reproduce it, and keep you informed as we work on it. We will not pursue a researcher who reports in good faith and stays within the rules below.

4. Scope

In scope: datajewellers.com, the sign-in portal at business.datajewellers.com, the demo at demo.datajewellers.com, the operator console at superadmin.datajewellers.com, and the desktop application. Our hosting and database providers' own infrastructure is theirs — report issues in it to them.

5. Rules — what not to do

Testing that breaks these rules is not authorised and is not protected by section 6:

• Do not touch other businesses' workspaces or real customer data. Test only against your own workspace or the demo.
• Use the demo at demo.datajewellers.com for anything that writes. Creating, editing or deleting records belongs there — and even there, do not degrade it for other visitors.
• No denial of service — no load testing, flooding, resource exhaustion, or deliberately tripping other users' rate limits.
• No destructive testing against production. No deleting or corrupting records, dropping schemas, or tampering with audit logs or backups.
• No social engineering. Do not phish, call, message or pressure DataJewellers staff, a business's staff, or our providers, and do not attempt physical access.
• No automated scanning that generates load. Crawlers, fuzzers and vulnerability scanners against our hosts are not permitted; targeted, low-volume manual testing is.
• No public disclosure before a fix. Give us a reasonable chance to fix the issue and tell affected businesses; talk to us about timing, and we will not use this to sit on a problem indefinitely.
• Do not keep what you find. If you come across real personal or business data, stop, do not copy or retain it, and say so in your report.

6. Safe harbour

If you follow this page — good-faith research, in scope, within the section 5 rules, reported promptly to support@datadoodlestech.com and not disclosed before a fix — we will treat your work as authorised and will not pursue a claim against you over it. That covers our own claims only; it binds no one else, and it does not extend to activity outside these rules, including anything that would breach Nepal's Electronic Transactions Act, 2063 (2006), under which unauthorised access to and damage of computer systems is an offence.

7. Suspected unauthorised access or a compromised account

If an account may have been taken over, or someone is in a workspace who should not be:

1. Business owners and administrators: deactivate the user in Settings straight away — it revokes their sessions at once and is faster than waiting for us.
2. Change affected passwords, then contact support@datadoodlestech.com with what you saw and when, including the relevant audit-log entries.
3. Do not delete records to "clean up" — the audit trail is what lets you and us work out what happened.

8. How we handle an incident

If we confirm a security incident affecting business data, we will contain it, assess what was affected, inform affected businesses without undue delay once the facts are confirmed, tell them what we know and what we recommend, and record the incident and our response in our own audit records. Nepal law sets no statutory breach-notification deadline for a private service of this kind; this is a commitment we make anyway. Where applicable, DataJewellers will handle personal information in accordance with applicable law. See also the Privacy Policy.

9. No bounty programme

DataJewellers runs no bug bounty or paid vulnerability-reward programme, and reporting an issue does not entitle you to payment. We are grateful for good reports and will credit you if you would like, but please do not report expecting a reward.

10. Contact

Security: support@datadoodlestech.com. Anything else: Legal & Compliance Contact.