Legal technology in India has grown up fast. Case-management apps, e-filing helpers, contract trackers and client portals now hold some of the most sensitive material a person ever shares: property papers, family disputes, criminal complaints, company secrets. That makes legal app security a matter of professional duty, not a nice extra. This is a fictional story, stitched together from patterns that come up again and again, about a small Delhi team that learned the hard way why one big security review right before launch is not enough, and what they changed afterwards.

Names, the firm and the product below are invented for illustration. Nothing here is legal advice.

The setup: a client portal for a mid-sized law firm

Call the company Nyaya Desk. Four developers, one product manager, one designer. Their first big customer was a litigation firm in Delhi with offices in two other cities. The firm wanted a portal where clients could upload documents, see hearing dates, read short updates from their advocate and pay invoices.

The plan looked sensible on paper. Build features for ten weeks, then hand the whole thing to an outside reviewer for a security check in week eleven, fix whatever came up, and go live in week twelve. The managing partner liked that there was a named “security week” in the plan. It sounded responsible.

If you follow the news on this site, you already know how much regulatory attention digital data now gets. Our mid-June legal news roundup is a reminder that courts and regulators are paying closer attention to how personal information is handled, and the Digital Personal Data Protection Act, 2023 puts clear duties on whoever collects it. A law firm’s client portal sits right in the middle of that.

Week eleven: the review that came too late

The outside reviewer was thorough. The report ran to many pages, and the findings that mattered most were not small.

• A database password sat inside the code repository. It had been there since week two, when a developer wired up a quick test and forgot to move it. Every copy of the repository, on every laptop, carried it.
• The document upload accepted almost anything. No real check on file type or size, and uploaded files were stored with predictable names. Guess one client’s file name and you could guess the next.
• Two open-source libraries had well-known weaknesses. They had been added in week four for PDF previews and never revisited.
• Clients could, with a crafted request, see hearing dates for matters that were not theirs. The permission logic had been built on an assumption made in week one that nobody wrote down.

None of these were exotic. All of them had been introduced weeks earlier, quietly, at a specific moment in the work. By week eleven they were buried under everything built on top of them.

Why one week was never going to be enough

The team lead, a practical engineer we will call Meera, sat down with the product manager and tried to estimate the fix. The password leak meant rotating credentials and cleaning history. The upload problem meant redesigning storage. The permission flaw touched nearly every screen. Realistically, that was four to five weeks of rework, not one.

The firm was not happy. The managing partner put it bluntly: “You told me there was a security week. I assumed that meant the product was secure.” Meera’s honest answer was that the security week had worked exactly as designed. It found the problems. It just found them at the most expensive possible moment.

That is the core lesson, and it applies far beyond software. A single inspection at the end tells you what went wrong. It cannot stop things going wrong while the work is happening. Lawyers know this instinctively. Nobody drafts a long agreement and checks the definitions only on signing day; good drafting reviews each clause as it is written.

What Nyaya Desk changed: a small check inside each step

Meera did not throw out the outside review. She kept it, but moved most of the protection earlier, into the ordinary daily flow of work. The idea was simple: wherever a problem could enter, put a small, quick check right there.

At the feature-planning stage

Ahead of building any new screen, the team spent fifteen minutes asking one question in writing: “Who should be able to see this, and who must never see it?” For a legal portal, that question is everything. The answer went into the ticket, so the developer building the feature and the tester checking it worked from the same rule. The hearing-date flaw would have been caught right here, because the assumption would have been written down and challenged.

When writing code

They added an automatic scan that ran every time someone saved work to the shared repository. It looked for things that look like passwords, keys and tokens, and blocked the save if it found one. Secrets moved into a proper store; they chose HashiCorp Vault, though the specific product mattered less than the habit. The week-two password mistake would now be stopped within seconds, by the same developer, while the context was still fresh.

When adding a library

Every new dependency triggered a quick check against public lists of known weaknesses. They used Trivy for this. If something flagged, the developer either picked a different library or noted why the risk was acceptable. The PDF-preview problem would have surfaced in week four, when swapping the library was a ten-minute job.

Before code reached clients

A short release rule: no change touching uploads, payments or permissions went live without a second developer reading it with security specifically in mind. Not a full audit. Just a focused second pair of eyes on the risky parts.

Each of these checks was small. None took more than a few minutes on a normal day. Together, they meant that most mistakes were caught by the person who made them, on the day they made them.

Three months later

The firm agreed to a delayed launch. Nyaya Desk spent the extra weeks fixing the original findings and putting the new habits in place. Then they asked the same outside reviewer to look again before a second, larger release.

This time the report was short. A couple of medium findings, some suggestions about logging, nothing that blocked going live. The reviewer noted something interesting: the problems that remained were mostly ones that only a specialist would spot, which is exactly what an outside review is for. The everyday mistakes had already been filtered out upstream.

The managing partner, who had been sceptical, noticed something else. Releases became calmer. There were no more surprise delays at the end, because there were no more surprise piles of problems at the end.

Lessons for legal app security teams in India

You do not need to be a large company to work this way. A few practical takeaways from the Nyaya Desk story:

1. Ask the access question first. In legal software, who can see what is the single most important design decision. Write it down before building.
2. Catch secrets at the moment of saving. An automatic scan on every save is cheap and stops one of the most common, most embarrassing leaks.
3. Check libraries when you add them, not months later. The cost of switching grows every week you wait.
4. Keep the outside review, but stop relying on it alone. It works best as a final safety net under many smaller nets, not as the only one.
5. Treat client data like a court file. If you would not leave a physical file open on a reception desk, do not leave its digital twin unprotected in a test database.

Regulation keeps moving, too. Following developments such as those in our digest of legal updates from 12 June 2026 helps product teams anticipate where expectations around data handling are heading, rather than reacting after a client or regulator asks awkward questions.

Where software teams learn this way of working

Meera’s team picked up much of this the slow way, through a painful week eleven. Developers who want to skip that pain can study it directly. DevSecOpsSchool’s training on stage-by-stage software security teaches exactly this discipline: placing a small control at each phase of delivery, such as threat modeling while planning, secrets and static analysis while coding, and policy gates before release. It offers role-based certifications, from a hands-on engineer track to a manager track focused on governance and team culture, along with consulting for organisations that want help building secure delivery pipelines.

For a legal-tech startup, that kind of grounding is worth having before the first big client, not after the first bad report.

The takeaway

The Nyaya Desk story is invented, but the pattern is real. Security that lives only at the end of a project finds problems when they are hardest to fix. Security woven into each step, through small and boring checks, finds them while they are still small. For anyone building software that holds people’s legal lives, that difference is not technical detail. It is part of earning their trust.