How we work

From Security Findings to Verified Fixes.

Anvexa helps Indian startups and MSMEs understand their security risks, prioritise fixes and verify remediation. From initial scoping to final handover, you’ll know what is being tested, who is responsible and what happens next.

Before testing begins

Agree How the Work and Your Information Will Be Handled.

Authority and Scope

Confirm which systems you own or have permission to test, including any restrictions from hosting providers or other third parties.

Operational Safeguards

Agree when testing can run and when it must stop. Where practical, use staging (a separate test environment) and synthetic data (invented test records). Testing can affect availability, so plan safeguards and backups first.

Confidentiality and Handover

Agree who can receive findings, how access and evidence will be shared, how long records are kept and when test access will be removed.

Customer Journey

From Your First Enquiry to Handover.

Enquiry
Written Proposal
Authorisation
Assessment
Remediation
Retest
Handover

Delivery Methodology

What Each Delivery Stage Includes.

Vulnerability Assessment and Penetration Testing (VAPT) identifies security weaknesses and checks their practical impact within the agreed scope. OWASP guidance helps inform relevant web application and API checks.

Stage 1

Discover

Scoping call and environment walkthrough
Attack-surface mapping: list agreed systems and exposed entry points
Testing scope, permissions and safeguards documented
Defined success criteria

Stage 2

Assess

VAPT guided by relevant OWASP web and API risks
Risk ranking by business impact
Executive and technical reporting
Prioritised remediation roadmap

Stage 3

Remediate

Findings converted to tracked tasks
Owners and deadlines assigned
Fix guidance and implementation questions
Where scoped, link findings to relevant framework controls

Stage 4

Verify & Handover

Agreed fixes retested within the retest window
Resolved and outstanding findings recorded
Reports and verification evidence handed over
Further reviews or monitoring scoped separately

Retest coverage: Your proposal defines which fixes will be rechecked, the number or extent of retests, the time limits and any additional fees. A retest checks agreed fixes; it is not a new full assessment.

Ongoing services: Scheduled reassessments are periodic security checks. Monitoring reviews agreed security signals, while incident response supports handling an incident. Each needs its own scope; monitoring hours and response availability must be confirmed separately.

Working Together

Who Does What.

Your Team

Provides written authorisation and confirms the systems in scope.
Arranges agreed access, test accounts and a technical contact.
Implements fixes through your developers or IT team, unless implementation support is separately contracted.

Anvexa

Works within the agreed scope, testing window and safeguards.
Shares findings, supporting evidence and recommended fixes.
Retests agreed changes within the proposal's retest window and records the results.

Following Through

From a Report to Verified Action.

The difference is what happens after a finding: an owner, an agreed deadline, fix guidance and a recorded retest.

Traditional Approach

VAPT Report

Spreadsheet

Manual Fix

Audit Scramble

Repeat

The Anvexa Approach

Finding

Risk Ranking

Named Owner

Agreed Deadline

Guided Fix

Verified Re-Test

Recorded Evidence

Scheduled Review

Reporting Example

An Illustrative View of Findings and Follow-Up.

The sample below shows how a finding connects the technical evidence to business impact, a recommended fix and the next verification step. Your proposal confirms the reports and format included.

Synthetic Example

A User Can Read Another Account's Invoice.

Example Severity: High

Invented test accounts and records, not a customer engagement. Severity depends on the exposure and business context.

Evidence: In a test environment, Account A requests /api/invoices/INV-DEMO-B. The API returns an invoice belonging to Account B instead of denying access.
Business Impact: A signed-in user could read another customer's billing information if the same access-control weakness exists on other invoice records.
Recommended Fix: Check the user's permission to access each invoice on the server. Apply the check to every invoice endpoint and add tests for cross-account access.
Retest Status: Not retested in this example. After a fix, check that Account A is denied access to Account B's invoice while authorised access still works.

See What Your Assessment Includes