Banking · Co-operative banks · NBFCs
The inspection is scheduled. The evidence is not.
A bank rarely fails an inspection because a control was missing. It fails because nobody could evidence that the control was working on the date in question — and reconstructing that after the fact costs weeks of a team that does not have weeks. Primary (Urban) Co-operative Banks feel this hardest: the same graded framework applies as at a large bank, against a security team that is often one or two people.
What actually goes wrong
- Evidence assembled manually per inspection, from tools that disagree with each other
- Patching timelines demonstrable in aggregate but not per critical system
- Vendor and outsourced-service risk owned by the bank regardless of who caused it
- Incident reporting measured in hours, against a process last tested in theory
- A findings backlog too large to close, with no defensible basis for what was deferred
What changes here
- Control coverage computed continuously from live findings, so drift shows in week two
- Every piece of evidence traceable to the finding and asset behind it
- Deferrals recorded as risk acceptances with an owner and an expiry, not as silence
- One control mapped across every framework that references it
- Append-only audit log, enforced in the database rather than by convention
The asset that cannot be patched: the core banking system, and whatever still talks to it over a protocol nobody wants to touch. Compensating controls around it have to be evidenced as deliberately as a patch would be.
Take the RBI readiness check — 10 questions, nothing stored →Manufacturing · Energy · Utilities
The scanner that would find it is the scanner that would stop the line.
IT security practice assumes you can probe an asset and patch it. On a plant floor both assumptions fail: active scanning can knock over a PLC, and the maintenance window that would allow a patch is a quarterly negotiation with operations. So the OT estate is usually documented in a spreadsheet, and the spreadsheet is usually wrong.
What actually goes wrong
- No trustworthy asset inventory below Purdue Level 3 — you cannot secure what nobody has listed
- Flat networks where a compromised engineering workstation reaches the control layer
- Remote vendor access into cells, standing rather than brokered
- Controllers running firmware with no available fix and no planned outage
- IT and OT reporting risk separately, so nobody holds the path that crosses between them
What changes here
- OT asset inventory and posture assessed against IEC 62443 foundational requirements
- Zone and conduit mapping on the Purdue model, so segmentation claims are checkable
- Attack paths that cross the IT/OT boundary treated as one path, because an attacker does
- Risk ranked by reachability and consequence rather than CVSS, which was never built for a controller
- Findings carry the 62443 reference, so remediation and audit are the same conversation
The asset that cannot be patched: a PLC on unsupported firmware running a process that stops if it reboots. The honest goal is not remediation — it is knowing exactly what can reach it, and proving that stays true.
Hospitals · Diagnostics · Health technology
Clinical uptime beats every security argument, and it should.
A hospital's constraint is not budget or awareness — it is that the imaging system cannot go offline, the vendor will void support if you touch the appliance, and the patient data on it is the most sensitive record the organisation holds. Security has to work around clinical operations rather than interrupt them.
What actually goes wrong
- Connected medical devices excluded from patching by vendor contract
- Legacy clinical applications reachable far more widely than anyone believes
- Patient data spread across systems nobody has fully inventoried
- Broad shared clinical accounts, because emergency access has to be instant
- Third-party access for device maintenance, rarely time-bounded
What changes here
- Devices inventoried and risk-ranked by exposure, not by whether they can be patched
- Data-security findings tied to the systems holding sensitive records
- Identity exposure surfaced per finding — who can reach this, and through which account
- HIPAA Security Rule coverage derived from live findings, not from a questionnaire
- Compensating controls recorded as the accepted answer where a patch is contractually impossible
The asset that cannot be patched: the imaging or lab appliance whose vendor contract forbids modification. It stays on the risk register with an owner and a review date — which is a defensible position, where an unowned exception is not.
SaaS · Product engineering · Digital businesses
You have the tools. You have too many of the tools.
A product company usually has SAST, SCA, a cloud posture tool, a scanner and a bug bounty — and a backlog nobody believes. The problem is not detection. It is that five tools produce five asset lists and five severities, and the reconciliation is somebody's whole job. Meanwhile the AI features shipped last quarter are in none of those tools' scope.
What actually goes wrong
- The same issue counted several times because each tool names the asset differently
- Severity assigned without knowing whether the service is internet-reachable
- Engineering rejects the queue as noise, which is a rational response to a bad queue
- Customer security questionnaires answered by hand, repeatedly
- Agents, model endpoints and vector stores in production with no owner and no inventory
What changes here
- Deduplication on rule identity and asset, so one issue is one item
- Priority computed from exposure, exploitation activity and business criticality together
- Findings routed to the team that owns the service, not to a central inbox
- SOC 2 and ISO evidence derived from the same findings engineering is already fixing
- AI infrastructure discovered and assessed alongside everything else, in one queue
The asset nobody registered: the agent a team shipped with a broadly-scoped key. It is not in your CMDB, and it is not in your CNAPP — which is the specific gap AI-Interceptor exists to close.
How AI-Interceptor finds it →Government · Public undertakings · Critical infrastructure
Many departments, one accountable signature.
Public sector estates are federated by design — departments procure their own systems, on their own timelines, with their own vendors. Security posture then has to be reported centrally, which means the reporting layer is doing the work that consistent architecture would otherwise have done.
What actually goes wrong
- No consolidated view across departments, each with a different toolset and maturity
- Long-lived legacy systems that predate current standards and outlast current staff
- Contracted operators holding the access, while accountability stays with the department
- Incident reporting timelines that assume a level of visibility nobody has
- Posture reported as a periodic document, stale before it is circulated
What changes here
- Multi-tenant separation with strict per-tenant isolation, enforced at the database
- Rolled-up posture across departments with drill-down to the finding underneath
- Every asset resolved to an owning department and business service
- Air-gapped and on-premise deployment where data cannot leave the estate
- Complete audit trail of who saw and changed what, append-only
The constraint that shapes everything: data residency and isolation. If the platform cannot run inside your boundary, the rest of the conversation does not happen.
Deployment options →Worth saying plainly
These are the sectors the product was built against, not a logo wall
Prak Knit is early. What is on this page is grounded in the frameworks and modules that actually ship — the RBI UCB control library, IEC 62443 posture checks and Purdue zoning, HIPAA and SOC 2 control mappings, and the AI inventory work. What we are not going to do is imply a customer base we have not earned yet.
The practical consequence is in your favour: early customers shape the roadmap, and we will tell you honestly whether your sector's hardest problem is something we solve today or something we would be building alongside you.
Tell us your estate. We'll tell you what we'd actually see.
Thirty minutes, your architecture, and a straight answer about coverage — including the parts we would not cover.