Security at Avisha Global.

How this website is built, and why that matters

We sell security testing, so it is fair to ask what our own site looks like from outside. It is deliberately boring. Every page is static HTML, CSS and JavaScript, generated from templates and uploaded as flat files. No application server executes your requests: no database behind the public site, no login, no sessions, no payments, no file upload, no user-generated content. That is not sophistication — it removes categories of vulnerability by construction rather than by configuration.

• No query layer in the request path, so injection has nowhere to land.
• No accounts: no authentication bypass, no session fixation, no password store to lose.
• No user-generated content, so no stored cross-site scripting.
• No admin console, no plugin ecosystem, no third-party theme code on the server.

The one component that accepts input: the contact form

One form, posting to a short PHP handler that validates the submission and sends it to us as email over authenticated SMTP through Google Workspace. Nothing is written to a database, because there is none.

• Server-side validation on every field. Browser validation is a convenience, not a control; the checks run again where nobody can skip them.
• CR and LF stripped from every value before it reaches a header — the specific defence against mail header injection, where a newline in a submitted field lets someone append headers and add recipients.
• A fixed, non-user-controllable recipient, set in server-side code. No request parameter can change it, so the form cannot be used as an open relay.
• A honeypot field a human never sees and never fills; completed submissions are discarded. Spam handling without a CAPTCHA.
• SMTP credentials stored outside the web root — not served, not in the document tree, not in any client-side JavaScript.
• No attachments accepted; to send a document, we agree a channel.

How we handle your data during an engagement

This matters more than our website. Consulting work means holding asset inventories, architecture diagrams, test credentials, findings that describe exactly how to break something, and sometimes personal data — in aggregate, more sensitive than what we are asked to test.

• NDA and confidentiality as standard, in place before detailed scoping information changes hands.
• Least privilege and need-to-know: the lowest access that completes the work, read-only where reading is enough, a reason attached to any administrative credential, and visibility limited to the consultants on that engagement.
• Testing only inside an authorised written scope. Rules of engagement — asset list, windows, exclusions, prohibited techniques, emergency contacts — signed before anything is touched. We do not widen scope on a verbal nod.
• Test accounts are time-boxed and revoked at closure. We also say when a credential you issued is over-privileged.
• Findings are client-confidential: no client named without written permission, nothing reused in collateral. Reports reach named recipients through an agreed secure channel, not an attachment on an open thread.
• Return or deletion at the end, on an agreed schedule, confirmed when done. Better still: where a redacted extract or synthetic dataset does the job, we take no copy of production personal data.

These are principles; the binding version is your contract and NDA. If you need a specific control, retention period or notification duty written in, say so before the work starts.

Access control and device practice on our side

A small firm with few systems: Google Workspace, the hosting control panel, DNS and Cloudflare, code repositories.

• Administrative access uses individual, named accounts. Nothing that can change the site, the DNS or the mail domain sits behind a shared login.
• Credentials live in a password manager, never in chat or email bodies. Client secrets stay in whatever store the client specifies.
• Laptops used for client work have full-disk encryption and screen lock; client material stays in the engagement workspace, not on personal devices or consumer cloud accounts.
• Access is removed when someone leaves an engagement or the firm, and their credentials rotated, not just disabled.
• To be confirmed: whether two-factor authentication is enforced by administrative policy across all Workspace, hosting, DNS and repository accounts, or is enabled account by account — say which, precisely.

What we do not have is a centrally managed device fleet, mobile device management, or endpoint detection on every machine. For a firm this size that is defensible — and better said than dressed up as an enterprise programme.

If something goes wrong

We keep no incident response retainer for our own website, which would be odd for a static site. What we have is an order of operations: contain, understand, tell the people affected, fix, write down what changed. Containment here is simple — the site rolls back or redeploys from source, the form handler can be disabled on its own to remove the only executing code path, and credentials rotate quickly.

For client engagements the commitment is more serious. If an incident on our side touches your material, we contact your named engagement contact directly and promptly — not a status page, not a quarterly summary. You get what we know, what we do not yet know, what data was involved and what we are doing, then updates until closure. We do not wait for certainty: an early call with incomplete information beats a complete report a fortnight later.

Where engagement data includes personal data, we act as a processor on your instructions. Breach notification to the Data Protection Board of India and to affected individuals under the Digital Personal Data Protection Act, 2023 is your duty as Data Fiduciary; our job is the facts and timeline, fast enough to discharge it.

Who else touches anything

Every extra vendor is another place your information could be. The list is short on purpose.

No analytics warehouse, no CRM wired to the form, no marketing automation, no chat widget pulling in a fourth-party script. For client work, any additional processor — a model provider, a cloud region, a specialist tool — is named in the engagement documentation before use and is subject to the residency requirements you set. Our Privacy Policy covers what we collect and why; this page covers how it is protected. Questions, including about the gaps above: [email protected] or +91-9891983813.