Find the gaps before attackers do

Security testing checks your software for weaknesses before someone with bad intentions finds them. With your written permission, testers look at your apps, APIs and servers from the outside, as a customer and as a member of staff, and ask one question again and again: can this person see or change something they shouldn’t?

There are two common kinds of test. A vulnerability assessment looks broadly for known weaknesses, mostly with automated tools, and lists them. A penetration test goes deeper by hand and confirms whether a weakness can really be used and what it would expose. In India the pair is often called VAPT, and most businesses need a bit of both.

Security testing is not a promise that software can never be broken. It is a careful look within an agreed scope and time, which removes the gaps that are most likely to hurt you and shows you where the remaining risk sits.

The best time to test is before something important depends on the software. That might be a launch, a big customer who will put their own data in it, a funding round, an audit, or a move to new servers.

Testing also pays off after big changes, such as a new payment flow, a new mobile app, a new integration with a partner or a rewrite of how logins work. These are the places where new gaps usually appear.

Some businesses carry more risk by the nature of their work: anyone handling payments, loans, health records, children’s data, identity documents or other people’s money. For them, a yearly deeper test and checks with every release are a sensible baseline, and their customers and regulators increasingly expect to see both.

We test nothing until the owner of each system has agreed in writing. Testing someone’s software without permission is illegal in most countries, including India, and a professional test starts with paperwork for that reason.

The scope lists what may be tested (the web addresses, apps, APIs and cloud accounts), what may not, the test window, the user roles we will use, and the contacts on both sides. Services run by others, such as your cloud provider, payment gateway or email service, are tested only within the rules those providers publish, and their own systems stay out of scope.

We also agree how we will behave on live systems. Where possible we test a copy; on live systems we avoid anything that could slow customers down or change real data, and we stop and call if anything looks wrong.

Most serious gaps in modern software are about access: one customer seeing another’s orders, a staff member reaching an admin screen, or an API that hands back more data than the app shows. We check every user role against every important screen and API.

We also check how logins, passwords, two-factor and sessions work; how forms and file uploads handle unexpected input; what error messages give away; and whether the business rules hold, such as a discount that can only be used once or a refund that needs approval. The OWASP Top 10 and the OWASP Application Security Verification Standard (ASVS) give us a shared checklist, and your own workflows show us where to look hardest.

A mobile app is two things to test: the app on the phone and the APIs it talks to. On the phone, we check what the app stores, whether login tokens and personal data are kept in the phone’s secure storage, and what someone could learn from a lost or shared device.

Between the phone and your servers, we check that every connection is encrypted and that the servers do not trust the app blindly. Anyone can copy an app and change how it behaves, so every important rule, such as who may see an order or how much a customer pays, must be checked on the server too. We test Android and iPhone versions separately, because they store data differently.

Many incidents start with something nobody remembered was switched on. We list what is open to the internet and look for forgotten test servers, storage that anyone with the link can read, admin panels without two-factor, old backups and accounts of people who have left.

We also review the code and its open-source libraries for known weaknesses, and search for passwords and keys left in the code or its history. In your cloud accounts on AWS or Google Cloud, we check who holds which permissions, whether logging is switched on, and whether backups can be restored by the right people and not by the wrong ones.

A report is only useful if your team acts on it. Ours opens with a short summary in plain words for the owner or manager: what was tested, what was found, and what to fix first.

Each finding then gives what we found and where, how serious it is and why (rated Critical, High, Medium or Low against your business, not a generic score alone), the evidence with any personal data masked, and the fix in terms your developers can follow. We confirm every finding before reporting it, so your team doesn’t spend days chasing false alarms. Then we walk through the report together on a call.

A finding is closed only when a retest shows the fix holds. We help your developers understand each fix, review their changes if they wish, or make the fixes ourselves.

After the retest you receive a summary of what was tested, what was found and what was closed. You can share it with customers, partners or auditors who ask how your software is tested. Where a regulator or customer needs a report from an empanelled or accredited auditor, our test and fixes prepare you for that audit, and we fix what the auditor finds. The lending platform we built for an NBFC in Kolkata went through independent vulnerability assessment and penetration testing before launch, and every finding was fixed.

Security testing often has a reason beyond good practice. In India, the Digital Personal Data Protection Act 2023 expects businesses to protect personal data with reasonable safeguards, CERT-In’s directions require certain incidents to be reported quickly and logs to be kept, and the RBI expects regulated lenders and payment businesses to test their systems.

Abroad, GDPR applies to data about people in Europe, health software is held to HIPAA-style privacy expectations in the United States, and card payments follow PCI DSS. We plan the scope around what you need to show and map our findings to it, so your evidence is ready when someone asks. We don’t issue certificates; we make sure the software behind your answers holds up.

One test a year does not keep up with weekly releases. We add automatic checks to your build pipeline in GitLab or GitHub: scans of your code and libraries, a search for secrets, and a scan of the running test site, so common mistakes are stopped before they reach customers.

Around that, a few habits do most of the work: libraries kept up to date, two-factor on every admin account, access removed on the day someone leaves, logs that are kept and read, and a deeper test before big launches or after major changes. We can look after all of this as part of ongoing support, so security stays part of the routine rather than a yearly scramble.