How We Handle Access And Data

02 · Due Diligence

Vendor Due Diligence

• We sign a mutual NDA before any system access is requested, including for the initial audit.
• We complete your organisation's vendor security questionnaire as part of onboarding.
• Engagement terms - scope, access, data handling, rules of engagement and deliverables - are agreed in writing before work begins.
• Where your organisation requires a data processing agreement, we work from your template.

03 · Contracting

Contracting

• Engagements run under a master services agreement, with a statement of work for each piece of work setting out its scope, deliverables, access and fee.
• The initial audit runs under the mutual NDA and a written scope, before any commercial agreement exists.
• Where your procurement process requires its own contract templates, we work from yours.
• Fees are invoiced in INR for clients in India and in USD for clients outside India. Model and infrastructure spend is never part of our fee: you pay your providers directly.

04 · Access

Access Model

• Read-only by default. The audit and most assessment work need viewer-level access only, and change nothing in your systems.
• No shared credentials. Access is granted through each platform's own permission system to named individual accounts. We never ask for, accept or store passwords or production secrets.
• Least privilege. We request the narrowest role that allows the work, and you can revoke it at any time without rotating anything.
• Write access is exceptional. Where implementation work needs it, it is scoped to a named system, agreed in advance and time-limited.
• Access ends with the engagement. We ask for all access to be revoked at the close of each engagement and confirm when it has been.

05 · Testing

Rules Of Engagement For Adversarial Testing

No adversarial testing - red-teaming, prompt-injection testing or any other attempt to make a system misbehave - begins without written authorisation from the system owner. That authorisation sets out:

• the systems and environments in scope, and those explicitly out of scope;
• the testing window;
• the techniques permitted;
• stop conditions, and a named contact on each side for immediate escalation.

Testing runs against non-production environments wherever they exist. Where production testing is necessary, it is agreed explicitly, limited to non-destructive techniques, and never involves real customer data beyond what the authorisation permits. If testing reveals a critical issue, we report it to your named contact immediately rather than waiting for the final report.

06 · Data

Client Data

• Work stays in your environment wherever the task allows, so data does not move.
• Where an extract is unavoidable - an evaluation set, a trace export - it is minimised and redacted at the point of capture.
• Client data is never used to train any model and never carried from one client's engagement into another's.
• Anything held outside your environment is deleted within 30 days of the engagement ending, or sooner on instruction, and we confirm deletion in writing on request.
• For personal data inside your systems, you remain the Data Fiduciary under India's DPDP Act and we act only on your instructions.

The full position is in the Privacy Policy.

07 · AI Tools

Use Of AI Tools

Where a client approves it, the provider, the purpose and the provider's data-retention terms are named in writing before anything is sent, and personal data is excluded wherever the work allows. Every AI-assisted draft - a finding, a summary, a test case - is reviewed by a person before it is used or reported.

08 · Third Parties

Third Parties

The complete list of third parties involved in running this website and our service:

None of these receives client system data. A client's own platforms - repositories, model providers, observability and cloud consoles - are accessed in place, under the client's permissions.

09 · Incidents

Incident Notification

If we become aware of a security incident affecting client data or access in our possession, we notify the affected client without undue delay and in any case within 24 hours, with what we know at that point, and keep them updated as the picture develops.

We support clients in meeting their own reporting obligations, including the six-hour reporting requirement under the CERT-In Directions of April 2022 and breach notification under the DPDP Act.

10 · Continuity

Continuity

Engagements are founder-led, so it is fair to ask what happens if the founder becomes unavailable. The answer is designed into the access model rather than left to a promise:

• Nothing is held hostage. Everything we build lives in your repositories and environments from the first commit, so work in progress is already yours.
• No one else holds your access. Access is granted to named accounts through your own permission systems, and you can revoke all of it yourself at any time without rotating a secret.
• A named continuity contact. Each engagement agreement names a contact who can confirm that access has been revoked and that any data held outside your environment has been deleted under the 30-day rule above.

11 · Frameworks

Frameworks

Findings and evidence are mapped to the frameworks your organisation reports against, so they can be used directly by your security, risk and compliance teams. The most common are:

• OWASP Top 10 for LLM Applications - application-level AI security risks.
• MITRE ATLAS - adversarial techniques against AI systems.
• NIST AI Risk Management Framework - AI risk governance.
• ISO/IEC 42001 - AI management systems.
• EU AI Act - obligations for systems placed on the EU market or used in the EU.
• India's DPDP Act, 2023 and the CERT-In Directions - personal data and incident reporting.

We are not a certification body and do not certify compliance with any of these; see Independence And Limitations.

12 · Website

This Website

• HTTPS only, enforced with HSTS.
• A strict Content Security Policy, and framing disallowed.
• No cookies, analytics, advertising pixels or third-party scripts; fonts, images and media are served from this domain.
• A published security.txt.

13 · Disclosure

Vulnerability Disclosure

If you believe you have found a security vulnerability in vetro.co.in, please report it to vetro.team.admin@gmail.com with "Security report" in the subject line, including enough detail to reproduce it.

What we commit to

• Acknowledging your report within three business days.
• Keeping you informed while we investigate and fix it.
• Not pursuing legal action against research carried out in good faith and within the rules below.

What we ask

• No denial-of-service testing, social engineering or physical attacks.
• Access or modify no data beyond the minimum needed to demonstrate the issue.
• Give us reasonable time to fix the issue before disclosing it publicly.

This policy covers vetro.co.in only. Client systems are never in scope, and we do not operate a paid bounty programme.

Last updated 1 October 2026.