VAPT: what it is and when a small business needs one

VAPT, short for vulnerability assessment and penetration testing, is a structured check of your applications and systems for weaknesses an attacker could use, followed by a controlled attempt to exploit them. A small business needs one when it launches something that handles logins, payments or customer data, when a customer or regulator asks for a report, or after major changes. This is not legal advice. TechSum coordinates VAPT with independent testing partners and handles remediation.

What is the difference between a vulnerability assessment and a penetration test?

A vulnerability assessment is mostly broad. Tools and reviewers scan your systems and list known weaknesses: outdated software, missing patches, weak configuration, exposed services. The output is a list ranked by severity.

A penetration test is narrow and deeper. A tester tries to exploit weaknesses, chain several small ones into a larger one, and show what an attacker could reach. They might use a flaw in a login flow to see another customer's invoice, for instance. The output is evidence, not just a list.

Most engagements combine both, which is why the name is VAPT.

What does a VAPT cover?

Scope decides everything. Typical targets:

• Web application: logins, sessions, forms, access control, file uploads, payment steps. Testers commonly follow the OWASP Top 10 and the OWASP Application Security Verification Standard.
• Mobile app: the app itself, how it stores data on the device and how it talks to the server.
• APIs: often where the real data sits, and a common source of broken access control.
• Infrastructure: servers, cloud configuration, network exposure, email and DNS settings.
• Internal network: office devices and shared resources, for companies with a physical office network.

Testers may work as black box (no inside knowledge, like an outsider), grey box (with a normal user account) or white box (with source code and documentation). Grey box usually gives the best value for a business application because it tests what a logged-in customer could do wrong.

When does a small business need a VAPT?

Look for a trigger:

1. Before launching an app or portal that takes logins, payments or sensitive data.
2. A customer asks: enterprise buyers often request a recent VAPT report in their vendor review. Some sectors and regulators ask for reports from auditors empanelled by CERT-In, so confirm the requirement before you hire.
3. After a major change: a new payment gateway, a migration, a rewrite or a new integration.
4. After an incident: to check that the hole is closed and nearby ones do not exist.
5. On a regular cycle: many businesses test yearly, or on each major release.
6. When building towards ISO 27001 or SOC 2: auditors expect evidence of testing. See ISO 27001 readiness for a small company.

The Digital Personal Data Protection Act, 2023 asks for reasonable security safeguards (section 8(5)). Regular testing is a sound way to show you take that seriously, though the Act does not name VAPT. Counsel advises on what the law requires of you.

What should you do before the test?

Fix the cheap things first. Paying testers to find a default password or an unpatched server wastes their time and your money. A short pre-test list:

• Update the operating system, framework and plugins.
• Turn on multi-factor authentication for admin and cloud accounts.
• Remove unused accounts, test pages and old subdomains.
• Check security headers and TLS settings. Our free health check covers the public side.
• Move secrets out of source code and rotate any that were ever exposed.
• Take a verified backup.

Test on a staging copy where you can. If the tester must touch production, agree windows, rate limits and a contact who can stop the test.

What happens during and after the test?

The steps are:

1. Scoping: what is in, what is out, what accounts the tester gets, which dates.
2. Rules of engagement: written permission for the testing, with contact details for both sides. Never allow unscheduled testing of systems you do not own.
3. Testing: typically a few days to a few weeks depending on scope.
4. Report: findings with severity ratings, steps to reproduce and recommended fixes. Many reports use the CVSS scale.
5. Remediation: your developers or ours fix the findings, starting with the highest severity.
6. Retest: the tester confirms the fixes. Ask for a clean letter or updated report you can share with customers.

How do you read the report?

Do not panic at the total count. A report with forty findings might hold three that matter. Sort by severity and by how easily someone could exploit each one. Group fixes by system so the work is practical. Look for patterns, because ten similar issues usually share one root cause, such as a missing check in a shared function.

Keep the report confidential. It is a map of your weak points.

What are the trade-offs?

A VAPT is a snapshot. Systems change daily, so a clean report today says little about next quarter. Pair it with routine habits: dependency updates, code review, monitoring and a patch schedule.

Cost and time scale with scope, so a narrow scope on the riskiest system is often better than a shallow pass over everything. Cheap, automated-only "VAPT" reports exist. They satisfy a form and miss the issues that matter. Ask what is tested manually.

Independence also matters. The team that builds a system should not be the only team that tests it.

Where does TechSum fit?

We scope the test with you, bring in independent testing partners, give them the access they need, and then fix what they find. We also harden systems before testing so the report is shorter. Read more on the Trust, Security and Compliance pillar, and start with the Digital Health Check if you want a first read on your public-facing security. The CERT-In reporting rule is the companion to this guide if something does go wrong.