Vulnerability audits are structured security assessments that identify weaknesses in applications, infrastructure, APIs, devices, cloud environments, and AI systems. For an AI startup, they are more than a compliance checkbox: a well-run audit can expose insecure model endpoints, leaked credentials, vulnerable dependencies, excessive cloud permissions, unsafe data pipelines, and flaws in the systems surrounding a model.
The strongest vulnerability audit programmes combine automated scanning with expert validation. Scanners provide breadth and speed, while security engineers determine whether a finding is exploitable, what business impact it creates, and how to fix it without disrupting production. This guide explains how to plan vulnerability audits, what they should cover, how findings are prioritised, and how Indian AI companies can turn audit results into measurable risk reduction.
What Are Vulnerability Audits?
A vulnerability audit is a systematic review of technical assets and configurations to identify, validate, rank, and track security weaknesses. It generally includes asset discovery, vulnerability scanning, manual testing, risk analysis, remediation advice, and a retest.
A vulnerability audit may examine:
- Web applications and mobile applications
- APIs, microservices, and authentication flows
- Cloud accounts, containers, Kubernetes, and serverless workloads
- Operating systems, network devices, endpoints, and databases
- Source-code repositories and open-source dependencies
- CI/CD pipelines and infrastructure-as-code templates
- AI model APIs, prompt-processing layers, vector databases, and data pipelines
- Secrets, identity and access management, logging, backup, and monitoring controls
A vulnerability audit is related to, but different from, a penetration test. A vulnerability assessment typically aims to identify a broad set of weaknesses, often using automated tools. A penetration test goes further by manually exploiting selected weaknesses to demonstrate attack paths and business impact. In practice, organisations often combine both activities under a broader security assessment programme.
Why Vulnerability Audits Matter for AI Startups
AI products introduce conventional application risks as well as risks connected to data, models, prompts, tools, and machine-generated output. An exposed model endpoint may enable account abuse, denial of service, extraction of sensitive information, or unexpected cloud costs. A compromised retrieval pipeline may expose private documents even when the underlying language model is secure.
Vulnerability audits help founders and engineering teams:
- Find exploitable weaknesses before public release
- Reduce the chance of data breaches and service disruption
- Satisfy enterprise customer security reviews
- Produce evidence for procurement, investor, and partner due diligence
- Protect intellectual property, proprietary datasets, and model weights
- Improve security before pursuing SOC 2, ISO 27001, or similar certifications
- Establish a repeatable process for fixing and retesting issues
For Indian startups serving banks, hospitals, government departments, or large enterprises, security evidence can directly influence sales cycles. Customers may ask for penetration-test reports, vulnerability-management records, secure development policies, access-control evidence, or data-protection documentation. An audit does not replace these controls, but it provides an important technical foundation.
What Should a Vulnerability Audit Cover?
The scope should be based on actual attack surfaces rather than only the assets that are easiest to scan. Before testing begins, create an inventory and classify assets by business criticality, data sensitivity, internet exposure, and ownership.
1. External attack surface
Review internet-facing domains, IP addresses, ports, TLS settings, DNS records, public cloud services, VPN gateways, email systems, exposed dashboards, and forgotten staging environments. External attack-surface discovery can reveal assets that the product team did not know were publicly reachable.
2. Web applications and APIs
Test authentication, authorisation, session handling, input validation, file uploads, business logic, rate limiting, error handling, and security headers. APIs deserve special attention because they often expose direct access to user records, model functions, internal tools, or expensive compute operations.
Important checks include:
- Broken object-level authorisation
- Privilege escalation and role confusion
- Weak password-reset and multi-factor authentication flows
- Injection vulnerabilities, including SQL and command injection
- Server-side request forgery
- Insecure direct object references
- Excessive data returned by API responses
- Missing rate limits and abuse controls
- Misconfigured CORS and exposed debugging endpoints
3. Cloud and infrastructure
Assess identity and access management, public storage, security groups, network segmentation, encryption, logging, backup, secrets management, container images, and administrative interfaces. In AWS, Microsoft Azure, or Google Cloud, excessive permissions are a common source of risk: a compromised workload should not automatically be able to read all customer data or modify production infrastructure.
4. AI and machine-learning components
AI-focused audits should examine both the model-facing interface and the surrounding application. Depending on the product, testing may include:
- Prompt injection and indirect prompt injection
- Sensitive-data disclosure through prompts or retrieved context
- Tenant isolation in retrieval-augmented generation systems
- Insecure tool or function calling
- Model endpoint authentication and rate limiting
- Training-data and fine-tuning-data access controls
- Unsafe handling of uploaded files and documents
- Poisoned or untrusted data sources
- Model and dependency supply-chain risks
- Excessive permissions granted to agents
- Output validation before generated content reaches downstream systems
AI security testing must be performed in a controlled environment. Test prompts should not contain real personal data unless there is a documented legal and security basis, and testers should not intentionally trigger destructive actions in production.
5. Dependencies and software supply chain
Modern products inherit risk from packages, container images, plugins, model libraries, operating systems, and build tools. Software composition analysis can identify known vulnerabilities using identifiers such as CVE, but teams must validate whether the affected component is actually reachable and exploitable in their environment.
Also review lockfiles, package provenance, dependency pinning, private registries, build permissions, and secret exposure in Git history. A dependency with no current CVE can still be risky if it is unmaintained or downloaded from an untrusted source.
Vulnerability Audit Process: Step by Step
Step 1: Define objectives and rules of engagement
Document why the audit is being conducted, which assets are included, permitted testing hours, prohibited actions, emergency contacts, data-handling rules, and reporting expectations. Confirm written authorisation from the asset owner. Testing systems without permission can create legal and operational risk.
Step 2: Build and validate the asset inventory
Collect domains, subdomains, IP ranges, cloud accounts, repositories, applications, APIs, environments, third-party integrations, and data stores. Ask engineering and operations teams to review the inventory; automated discovery alone may miss internal systems and temporary resources.
Step 3: Run authenticated and unauthenticated scans
Unauthenticated scanning reflects what an external attacker can see. Authenticated scanning can identify patch, configuration, and package issues that are invisible from outside. Use separate test accounts with least privilege, and ensure scanners cannot modify or delete production data.
Step 4: Perform manual validation
Security professionals should validate important findings, remove false positives, and test business logic that automated scanners cannot understand. For an AI product, manual review should include tenant separation, permission boundaries, prompt and retrieval flows, and the actions available to agents or integrated tools.
Step 5: Rate risk using context
Do not rank issues solely by scanner severity. Combine technical severity with exploitability, internet exposure, affected data, asset criticality, compensating controls, and potential business impact. A medium-severity issue on an unauthenticated model API may deserve faster treatment than a high-severity issue on an isolated test server.
Step 6: Remediate and document
Assign every confirmed finding to an owner with a due date. Record the affected asset, evidence, root cause, fix, risk acceptance decision if applicable, and verification status. Good remediation addresses the underlying class of weakness rather than only the specific vulnerable endpoint.
Step 7: Retest and close the loop
A vulnerability is not closed because a ticket says “fixed.” Retesting should confirm that the original exploit no longer works and that the change did not create a regression. For recurring issues, add a test to CI/CD, a secure coding guideline, or an infrastructure policy.
How Vulnerabilities Are Prioritised
Common vulnerability-management programmes use CVSS as one input, not the complete decision. CVSS considers characteristics such as attack vector, complexity, privileges required, user interaction, scope, and impact. Organisations should add business context.
A practical priority model is:
- Critical: Easily exploitable weakness affecting sensitive data, administrative control, or core availability; immediate containment and urgent remediation.
- High: Significant compromise is realistic, especially for internet-facing or privileged systems; fix on a short, defined deadline.
- Medium: Exploitation requires additional conditions or has limited impact; schedule remediation and monitor exposure.
- Low: Limited security impact or difficult exploitation; fix through normal engineering cycles.
- Informational: Hardening advice, configuration improvement, or evidence requiring review.
For each finding, ask: Can an attacker reach it? What identity is required? What data or action becomes available? Is exploitation already occurring in the wild? Does the weakness cross tenant boundaries? Can the issue be mitigated immediately while a permanent fix is developed?
Tools Used in Vulnerability Audits
Tool selection depends on scope and expertise. Common categories include:
- Network and asset discovery: Nmap and cloud-native inventory tools
- Web and API testing: Burp Suite, OWASP ZAP, and API security platforms
- Infrastructure scanning: Nessus, Qualys, Rapid7, or equivalent platforms
- Cloud posture management: AWS Security Hub, Microsoft Defender for Cloud, Google Security Command Center, and specialist CSPM tools
- Container and image scanning: Trivy, Grype, and registry-native scanners
- Code and dependency analysis: SAST, SCA, secret-scanning, and IaC-scanning tools
- Kubernetes security: kube-bench, kube-hunter, admission controls, and runtime monitoring
- AI security testing: Prompt- and agent-evaluation frameworks, custom abuse cases, and manual red-team testing
Tools produce evidence, not final risk decisions. Configure scan credentials carefully, keep signatures current, and avoid treating a clean automated report as proof that an application is secure.
Vulnerability Audit Report: What to Expect
A useful report should be understandable to both technical and business readers. It normally includes:
- Executive summary and overall risk view
- Scope, dates, environments, and limitations
- Methodology and tools used
- Asset and attack-surface summary
- Finding severity and prioritisation method
- Reproduction steps and supporting evidence
- Business impact and affected data or functions
- Specific remediation guidance
- Compensating controls and recommended timelines
- Management response or risk-acceptance record
- Retest results and closure status
Avoid reports that list scanner output without explaining exploitability or remediation. For customer due diligence, redact secrets, personal data, internal architecture details, and exploit instructions that could create additional risk.
Vulnerability Audits in India: Practical Considerations
Indian AI companies should align audit planning with the sensitivity of their data, contractual obligations, and applicable legal requirements. The Digital Personal Data Protection Act, 2023 establishes obligations related to processing digital personal data, including reasonable security safeguards. Sector-specific expectations may also apply when serving regulated customers, such as financial services, healthcare, insurance, or government organisations.
Consider the following operational points:
- Define whether data is stored or processed in India or other jurisdictions.
- Check contracts for customer-mandated penetration testing and notification timelines.
- Use qualified assessors who can protect confidential source code and datasets.
- Establish an incident escalation process before testing begins.
- Maintain evidence of access reviews, patching, logging, backups, and remediation.
- Map findings to internal controls and, where relevant, ISO 27001 or SOC 2 criteria.
- Ensure third-party AI APIs and cloud providers are included in the risk assessment.
Legal and compliance requirements change, so obtain advice appropriate to the organisation’s sector and processing activities. A vulnerability audit is one part of a broader governance and security programme.
How Often Should You Conduct Vulnerability Audits?
Frequency should reflect risk and change velocity. A common baseline is external scanning continuously or monthly, authenticated infrastructure scanning at least monthly or quarterly, and a full application penetration test after major releases or at least annually. High-risk AI systems may require testing whenever models, tools, retrieval sources, authentication, or data flows materially change.
Trigger an additional assessment after:
- A major architecture or cloud migration
- Introduction of agentic actions or new integrations
- A significant security incident or near miss
- Acquisition of a new codebase or infrastructure environment
- Changes to sensitive-data processing
- A new enterprise or government customer requirement
Common Mistakes to Avoid
- Scanning without a complete asset inventory
- Testing only production while ignoring staging and development credentials
- Relying on automated severity without business context
- Treating an annual report as a substitute for continuous vulnerability management
- Giving testers excessive credentials or unsafe production access
- Failing to validate false positives and false negatives
- Closing tickets without a retest
- Ignoring dependencies, cloud permissions, and third-party integrations
- Sharing unredacted reports containing secrets or personal data
- Testing AI models without assessing the application, data, tools, and permissions around them
Building a Continuous Vulnerability Management Programme
Start with ownership. Assign responsibility for asset inventory, scanning, triage, remediation, risk acceptance, and retesting. Then establish service-level objectives, such as urgent remediation for critical internet-facing issues and defined deadlines for high and medium findings.
Integrate security into engineering workflows:
1. Scan code, dependencies, secrets, containers, and IaC during pull requests or builds.
2. Block releases only for clearly defined, validated risks to avoid unmanageable alert fatigue.
3. Send findings to the engineering ticketing system with an owner and due date.
4. Monitor external exposure and newly disclosed vulnerabilities.
5. Use threat modelling for major product and AI architecture changes.
6. Track metrics such as mean time to remediate, overdue critical findings, recurrence rate, asset coverage, and retest closure rate.
7. Review trends with leadership, not just individual tickets.
The goal is not to produce the longest vulnerability list. It is to reduce the probability and impact of compromise while enabling the product team to ship safely.
Frequently Asked Questions
Are vulnerability audits the same as penetration tests?
No. Vulnerability audits usually emphasise broad discovery and risk assessment, while penetration tests use deeper manual exploitation to demonstrate attack paths. Many organisations use both together.
How much do vulnerability audits cost in India?
Cost varies with the number of applications, APIs, environments, test days, data sensitivity, and assessor expertise. A small startup assessment may be relatively focused, while a regulated enterprise or complex AI platform requires broader testing and retesting. Request a scope-based quote rather than comparing prices alone.
Can automated scanners replace security experts?
No. Scanners are valuable for coverage and repeatability, but they can miss business-logic flaws, tenant-isolation issues, insecure AI workflows, and exploitable chains. Human validation is essential for meaningful prioritisation.
Should a startup test its AI model or its application?
Both. Model behaviour, prompts, retrieval, tools, APIs, identity, cloud permissions, dependencies, and data stores form one connected attack surface. Testing only the model endpoint can miss the most serious weaknesses around it.
What should happen after an audit?
Triage findings, contain urgent exposure, assign owners and deadlines, implement fixes, document accepted risks, and conduct a retest. Feed recurring findings into secure design, engineering controls, and continuous scanning.
Apply for AI Grants India
If you are an Indian AI founder building a secure, high-impact product, explore funding and support opportunities through AI Grants India. Apply today to strengthen your AI venture’s path from technical innovation to responsible deployment.