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. Our nightly database dumps are separately encrypted with AES-256-GCM under a key the platform does not hold and which is not stored alongside them.

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.

Operator access

The platform console that spans every workspace is gated on a column separate from the workspace role, so a customer’s own administrator has no access to it. Eligibility is additionally restricted to addresses on the operator’s domain, the restriction is enforced when the role is read rather than only when it is granted, and only one configured owner account can grant or revoke it. The console can change a workspace’s plan and standing; it cannot read or alter a workspace’s filings, notes or evidence. Every action in it is written to a separate append-only log with the actor and their address.

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.

• Production access is held only by named individuals who need it, on the least privilege that does the job, and is removed on the day a person leaves. Today that is one person: the company has no other staff.
• Administrative access requires multi-factor authentication.
• Anyone who joins will be bound by confidentiality obligations surviving their employment, and trained on this policy and the Privacy Policy on joining and annually. Nothing is being relied on here today, because there is nobody to train.
• Customer content is read by us only where a Customer asks us to look at something, or where a specific security investigation requires it — and the access is logged.
• Every change passes an automated gate before it can reach the repository: type checking, redirect-safety and TOTP vectors, the two-factor policy and security-alert suites, password-reset and data-rights tests, and 75 authorisation and tenant-isolation checks run against a running application. A push is refused outright if any of them fails.
• System clocks are synchronised to the time sources of our hosting platform rather than directly to the National Informatics Centre or the National Physical Laboratory. The CERT-In Directions expressly permit another accurate and standard source for infrastructure spanning multiple geographies, provided it does not deviate from NIC and NPL, and that is the basis we rely on.
• ICT system logs — the runtime and edge records of who reached what, and when — are streamed off the hosting platform as they are produced and retained for 180 days in Mumbai, as the CERT-In Directions of 28 April 2022 require. A daily sweep deletes them at 180 days, because that period is a floor in those Directions and a ceiling in our own Privacy Policy.
• The database is dumped nightly to encrypted object storage in Mumbai, and each dump is retained for 30 days. The dump is encrypted with AES-256-GCM under a key held outside the database it protects, so the storage credentials alone do not read it. Restores are rehearsed rather than assumed: the restore path runs in the automated checks on every push, and quarterly against a copy of production. The evidence vault is separately durable — objects are replicated by the storage provider and are not held only on the database.

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.

The Directions require a designated point of contact to be registered with CERT-In and kept current. The role is assigned internally to our Data Protection Contact, whose details are on the Grievance Redressal page, and registration with CERT-In is outstanding as at 24 September 2026. We would rather record that here than imply a registration we have not made; it does not change who answers, or the six-hour clock above, both of which apply from today.

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.
• Our public pages — the marketing site and the legal centre — carry a Content-Security-Policy that permits inline script. The signed-in application does not: every route that displays statutory records is served a policy with no inline allowance at all, built on a value that changes with each request. An automated header scan reports the weaker of the two, because it cannot sign in to see the stronger one. The split is deliberate rather than unfinished: the strict policy depends on that per-request value, which cannot be embedded in a page generated once and served from a cache, so applying it to the roughly 120 public pages would make every one of them render individually in order to harden markup that contains no Customer data, no session and nothing a visitor can influence. We would rather explain a lower score than weaken the half that matters.
• Rate limiting inside the application is counted per instance rather than shared across instances, so behind several instances the effective limit is higher than the configured one. Since 26 September 2026 three rules at the edge of the hosting platform sit in front of it, each keyed to the requesting address, each answering 429 and holding that address off for a period once tripped: one on the authentication endpoints, one on the document routes, one on the remaining programmatic surface. They are deliberately set well above what an office behind a single address generates, because their job is volume rather than credential guessing — the per-account limit inside the application is what addresses that, and it is unaffected by instance count. The scheduled paths and the log delivery endpoint are exempt on purpose: throttling the last of those would discard the records the 180-day retention above exists to keep. An earlier version of this page described such a rule as already configured when it was not, which is the error clause 3 names; it is recorded here rather than removed now that the rule exists.
• 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.