Eradicating threats since 2014.

Threatsys Technologies Private Limited is a CERT-In empanelled cyber security company, certified to ISO 27001, ISO 20000 and SOC 2 Type II. We have been doing this since 2014, which in this industry is long enough to have been wrong about a few things and to have corrected them.

We work across both public and private sector, in fintech and banking, manufacturing, healthcare, IT and ITeS, energy, oil and gas, government and telecom, in India and in fifteen or more countries beyond it. That range matters less as a boast than as a reason we recognise the pattern in front of us: most problems we are shown, we have seen a version of before.

The 360 degree description gets used loosely by everyone, so here is what we mean by it. Offensive testing, regulatory audit and certification, managed defence, forensics when something has already happened, and the training that stops it recurring. One accountable team across all of it, rather than five vendors who each blame the other four.

We test the way an attacker with patience would, then prove the finding on your own systems with your engineers watching. If it cannot be reproduced in front of you, it does not go in the report. That single rule removes most of the argument that usually follows a security assessment.

Reports are written to be acted on rather than to demonstrate effort. An executive summary that answers the question a board actually asked, and a technical annexe an engineer can implement from. Re-testing is included, because a report is not a fix and we would rather see the finding closed than counted.

We are deliberately not the cheapest. What we try to be is the firm whose report you can hand to a regulator, an insurer or an enterprise customer without having to explain it first.

Our people hold offensive and defensive certifications from EC-Council, OffSec, ISC2, ISACA, CREST, IAPP, AWS and Microsoft, and several carry bug bounty acknowledgements from Facebook, Google, Microsoft, NASA, Sony, Mastercard, Adobe and others. Those are individual achievements rather than company marketing, but they tell you the testing is done by people who do this because they find it interesting.

You are told who is leading your engagement before it starts, and that person writes the report and attends the walkthrough. If they change, we tell you why. This sounds like a small commitment and it is the one clients mention most often.

Most security proposals describe a methodology. Very few describe what the fortnight feels like from your side, which is the part that determines whether the work lands. Here is ours, honestly.

It starts with a scoping conversation, not a questionnaire. Thirty minutes with an engineer who asks what the system does, who uses it, what would genuinely hurt if it stopped, and which regulator is going to read the output. That conversation regularly changes the scope. Sometimes it shrinks it, because the thing you were worried about is not where your risk actually sits.

You then get a written scope with the effort broken out by activity rather than a single number, a named lead, a start date and the list of what we need from you. That list is short and specific: test accounts at each privilege level, an environment that resembles production, a named technical contact who can answer a question inside a day, and written authorisation. Engagements that slip almost always slip on the environment or the accounts, so we ask early and chase.

During testing you hear from us. Anything critical is reported the day we find it rather than held for the report, because a live exposure that waits three weeks for a document is a decision nobody would defend afterwards. Otherwise there is a short weekly note: what has been covered, what is left, anything blocking.

The report arrives in two halves. An executive narrative your leadership can act on without a translator, and a technical annexe with the exact request, the payload and the reproduction steps for every finding. Both are written by the person who did the testing. We do not have a report writing team, deliberately, because reports written by people who were not there read exactly like reports written by people who were not there.

Then the walkthrough, where your engineers get to argue. That session is the most useful hour of the engagement and it is also the one most often skipped by firms who bill by the report. Findings get downgraded in that meeting when a compensating control we could not see turns out to exist, and occasionally upgraded when your team knows something about the data that we did not.

Finally retesting, included, until the findings are closed. Not a second engagement, not a discount on next year. A report describing a vulnerability that is still present is not a deliverable, so verifying the fix is part of the job rather than an upsell.

A company is defined at least as much by its refusals, so these are ours, stated plainly enough to be held to.

We will not issue a certificate that the testing behind it does not support. That means we will decline an engagement where the timeline allows for the paperwork but not the work, and we have done so. It is the single most common reason we lose a bid, and it is not negotiable, because a certificate from an empanelled auditor is only worth anything while it means something.

We will not report a finding we have not proved. Unverified scanner output does not appear in our reports under its own authority. Where something is suspected but not demonstrated, it goes in a separate observations section, labelled as such, so nobody has to guess which is which at three in the morning during a remediation sprint.

We will not invent numbers. You will notice this site is careful about statistics: where we say most engagements rather than eighty seven per cent, it is because we have not counted rigorously enough to claim the number. A security firm that rounds up its own metrics is telling you something about how it will round up yours.

We will not publish a client's name, logo or engagement detail without written permission, and we will not describe a finding in enough detail to be reusable against a live system. Several of the platforms we have tested serve crores of citizens; a case study that reads well and hands somebody a starting point would be indefensible.

We will not sell you a tool to solve a process problem. A significant share of the security spend we encounter went on technology that nobody has tuned since installation, bought to answer a question that was really about ownership and headcount. We would rather have the uncomfortable conversation.

We are headquartered in Bhubaneswar, with delivery reaching across India, the Gulf, Africa and Australia. Being based in Odisha rather than in one of the metros has had two effects on the firm that are worth naming.

The first is public sector depth. A large part of our early work was for state government platforms, which are unforgiving clients in the most useful sense: the systems serve people who have no alternative, the timelines are set by policy rather than by convenience, and the evidence has to satisfy an auditor rather than a stakeholder. Learning the trade on citizen platforms sets a standard that makes commercial work feel comparatively relaxed.

The second is retention. Our engineers are not cycling through a metro job market every eighteen months, which means the person who tested your platform in 2023 is frequently the person testing it in 2026. Continuity is invisible in a proposal and enormous in practice, because the second assessment of a system starts from what we already know rather than from the documentation.

International work travels on the method rather than the paperwork. The technique that finds an authorisation flaw in a Nigerian bank is the technique that finds it in an Indian one. What does not travel is the reporting: findings are framed against the obligations the client actually answers to, because a report citing the wrong regulator is a report the client has to translate before it is useful.

We audit other organisations for a living, which makes it reasonable to ask who audits us. The short answer is that we hold the same certifications we assess against, and we are surveilled on them between renewals.

ISO 27001 governs our own information security management, with annual surveillance audits rather than a certificate that sits on a wall for three years. ISO 20000 covers service management. SOC 2 Type II is the one worth understanding: unlike a point in time attestation, it tests whether controls actually operated across a period, which is a materially harder thing to pass and the reason we sought it.

Our own platforms are penetration tested independently, by people who did not build them. Access to client engagement data is role based and reviewed on the same quarterly cadence we recommend to clients, which is a rule that is easy to write and tedious to keep, and we keep it. Every engineer signs an individual confidentiality undertaking in addition to the firm's contract with you.

Client engagement artefacts, findings, screenshots, reproduction steps, are retained for the period agreed in your contract and destroyed on schedule. Credentials issued to us for authenticated testing are revoked by you at the end of the engagement, and we ask for confirmation that they have been rather than assuming it.

If you think we have a problem, our responsible disclosure route is monitored and answered, and we do not pursue researchers who follow it in good faith. Complete documentation, the Data Processing Addendum, the sub-processor list and our latest attestation reports, is available under NDA on request.