Overview
Most breaches at companies this size are not sophisticated. They are an admin panel left exposed, a dependency nobody has updated in two years, an API that trusts a user id sent in the request body, a backup that was never restored to check that it works. The work of preventing them is unglamorous, and it is almost entirely preventable.
We test and harden what we build and what you already run, then fix what is found and prove it is fixed. Where the question is regulatory rather than technical, we get your systems and your evidence into a state your auditors and your counsel can sign off — including India’s DPDP framework, whose consent-manager obligations arrive in November 2026 and whose full compliance date is 13 May 2027.
What we do
- Application security testing (VAPT) — web, mobile and API assessments run against the OWASP Top 10 and ASVS, with a report that ranks findings by severity, shows how each one was reproduced, and is followed by a retest once you have fixed them.
- Secure development — authentication and session handling, access control checked on every endpoint rather than only the ones with a menu item, input validation, secrets kept out of the repository, dependency and supply-chain hygiene, and security checks that run in CI instead of in somebody’s memory.
- Infrastructure hardening — server and cloud configuration, TLS, WAF and CDN rules, least-privilege access, a patching cadence somebody owns, and logging that would actually tell you what happened.
- Backups you have restored — a backup nobody has tested is a belief, not a plan. We restore one, time it, and write down the steps so the next person can follow them under pressure.
- Data protection and DPDP readiness — consent and notice on the pages that collect data, a record of what you hold and why, retention and deletion that happen on schedule, a breach procedure with names against it, and handling for the data-principal requests the Act expects.
- Evidence for audits and customers — the artefacts ISO 27001, SOC 2 and enterprise procurement questionnaires ask for, prepared alongside your auditor rather than in place of one.
How an engagement runs
- Scope first, in writing. Which systems, which environments, what is out of bounds, and who to call if a test causes a problem — agreed before anything is touched.
- Test, then explain. Findings arrive with the request that triggered them and the business consequence, not only a severity score.
- Fix, or be told what it would cost. We can remediate what we find or hand your team a prioritised list. Either way you get an honest view of what is worth fixing now and what can wait.
- Retest and record. A finding is closed when it no longer reproduces, and that retest is the document you show the customer who asks.
What this is not
We are not a certificate and we do not issue one. Certification comes from an accredited body, and legal sign-off comes from your counsel; our part is getting the systems and the evidence into a state where both go smoothly. Where a specialist is genuinely required — a CERT-In empanelled audit for a regulated filing, for instance — we will tell you that rather than sell you something adjacent to it.
Keeping it that way
Security is not a project that finishes. Most clients keep a light retainer afterwards: dependency and patch monitoring, uptime and error alerting, a quarterly review of access and exposure, and a retest after any significant release. It sits naturally alongside maintenance and support and the cloud and DevOps work, and it is the same discipline we apply when an AI feature starts handling customer data.
Getting started
Most engagements open with a short assessment of what is currently exposed — domains, endpoints, admin surfaces, dependencies, headers and certificates — and a call to walk through it. It takes a few days and tells you whether you have an urgent problem or a maintenance one. Ask for the assessment.