Information Security Policy

Section 8(5) of the Digital Personal Data Protection Act, 2023 requires a Data Fiduciary to take reasonable security safeguards to prevent a personal data breach. The Act does not enumerate them. Rule 8 of the Information Technology (Reasonable Security Practices) Rules, 2011 does, and names IS/ISO/IEC 27001 as a recognised standard.

We are candid about the current position: the controls below are implemented and verifiable in the software. We are not yet certified to ISO 27001 and do not claim to be. A certification claim we could not produce a certificate for would itself be a misrepresentation.

Encryption in transit

TLS 1.2 or better on every connection. HTTP Strict Transport Security is sent with a two-year max-age including subdomains, so a browser that has seen the site once will not be downgraded to plain HTTP afterwards.

Encryption at rest

The database and the evidence vault are encrypted at rest by the hosting platform. Backups are encrypted with the same keys.

Credentials

Passwords are stored only as bcrypt hashes with a per-password salt, are never recoverable, and are never logged. New and changed passwords are checked against a denylist of commonly guessed values and against the user's own name, email and organisation. There is no password-recovery path that emails a password, because no plaintext exists to email.

Sessions

A session is an HS256-signed token in an httpOnly, SameSite cookie, marked Secure in production so it cannot travel over plain HTTP. The signing key is validated at process start and a production process refuses to boot without a real one. Every request re-checks the token against the live user record, so deactivating a member takes effect on their next request rather than when their token would have expired.

Tenant isolation

Every query is scoped to one workspace at the data-access layer, not in the page that renders it. A single-record lookup composes the caller's scope with the requested id using AND rather than a spread, specifically so a restricted user's own scope filter cannot overwrite the id being asked for and quietly return a record they are entitled to instead of a 404.

Authorisation

Roles are enforced server-side on every route. Hiding a button is treated as a courtesy to the user, never as a control.

Response headers

A Content Security Policy that forbids framing the application outright (frame-ancestors none), nosniff, a strict-origin-when-cross-origin referrer policy so entity and filing identifiers in a path do not leak to outbound links, a restrictive Permissions-Policy, cross-origin isolation headers, and no-store on every authenticated response so a shared proxy cannot serve one workspace's page to the next person through it.

Rate limiting

Sign-in, sign-up and the federated token exchange are throttled per source address, with a block period longer than the window on the credential endpoints. Sign-in spends the same time on an unknown email address as on a wrong password, so the endpoint cannot be used to enumerate which addresses have accounts.

Input validation

Every request body is parsed against a schema before it reaches business logic; anything unrecognised is rejected rather than coerced. Database access is through a parameterised query builder, so a value can never be interpreted as SQL.

Uploads

Evidence files are stored outside the application root with generated names, served with a content type derived from the stored record rather than the filename, and never executed. Type and size are checked on the server.

Audit trail

Append-only. Every state change, reassignment, override, upload, sign-in and automation pass is recorded with the actor, the time and the source address. Nothing in the application deletes or edits an audit row.

Dependencies

Locked to exact resolved versions. Advisories are reviewed and a fix for a high-severity issue in a reachable path is applied within seven days.

• Access to production is limited to named personnel who need it, granted on the least privilege that does the job, and reviewed quarterly. Access is removed on the day a person leaves.
• Administrative access requires multi-factor authentication.
• Staff are bound by confidentiality obligations that survive their employment, and are trained on this policy and the Privacy Policy on joining and annually.
• Customer content is read by a member of our staff only where a Customer asks us to look at something, or where a specific security investigation requires it — and the access is logged.
• Changes reach production through review; nobody deploys their own unreviewed change to production.
• System clocks are synchronised to the Network Time Protocol servers of the National Informatics Centre or the National Physical Laboratory, as the CERT-In Directions of 28 April 2022 require, so log timestamps across systems are comparable in an investigation.
• ICT system logs are retained for 180 days within India, as those Directions also require.
• Backups are taken daily, retained on a 35-day rolling window, encrypted, and test-restored quarterly. A backup that has never been restored is a hope, not a control.

Three separate obligations run on three separate clocks, and they start when we notice, not when we finish understanding.

Our sequence: contain, preserve evidence, assess scope, report on the clocks above, remediate, then write up what happened and what we changed. We will send a first notice with gaps and follow it with updates rather than hold a complete report until the deadline has passed — a Customer with its own statutory clock running needs the early warning more than the finished analysis.

We maintain a designated point of contact for CERT-In and will keep the details current with them, as the Directions require.

Report it privately to contact@lawzer.in with enough detail to reproduce it. We will acknowledge within two working days, tell you our assessment within ten, and let you know when it is fixed.

What we ask of you:

• Test only against your own workspace. Do not access, alter or download data belonging to anyone else — a compliance workspace holds another organisation's confidential records.
• Do not run denial-of-service tests, send spam, or use social engineering against our staff or customers.
• Give us reasonable time to fix it before disclosing it publicly.
• Do not extract more data than is needed to demonstrate the issue, and delete what you took once you have reported it.

A security page that lists only strengths is not much use to someone assessing us. The current gaps, as at the effective date of this version:

• No ISO 27001 or SOC 2 certification. Controls are implemented, but not independently certified.
• Multi-factor authentication is available for administrators through the federated sign-in path, but is not yet enforceable by a Customer across all of its own users. It is on the roadmap.
• Rate limiting is per application instance rather than shared across instances, so behind several instances the effective limit is higher than the configured one. A platform-level rule should sit in front of it, and does in our own deployment.
• Email delivery of statutory reminders is not enabled by default. Until a sending domain is verified with SPF and DKIM, reminders are delivered in-app only — which is the honest position rather than dropping them silently.
• Penetration testing is annual. Between tests we rely on review, dependency scanning and the reporting path above.

This list is maintained rather than decorative, and items are removed from it when they are actually closed.