Privacy Policy

1. Who we are

Alphasoft Infotech Private Limited ("Alphasoft", "we", "us", "our"), a company incorporated in India (CIN U72900PN2021PTC204451), trading as "BreakMesh", operates the BreakMesh authorized website and application security scanning platform (the "Service").

Registered office: 11, Vrindavan Shilp Apt, S. No. 30/34, Pipe Line Road, Nashik, Maharashtra, India, 422001.

We currently direct and market the Service to customers in India and the United States. We do not currently direct or market the Service to residents of the European Union or the United Kingdom, and have not appointed a representative in either jurisdiction under Art. 27 GDPR / UK GDPR. This is expected to change as we expand into those markets — see §10 for what that means today if you access the Service from the EU or UK anyway.

For data protection queries or to exercise your rights, contact support@breakmesh.io. ( privacy@breakmesh.io is reserved for vulnerability disclosure and responsible-disclosure reports, not data-subject-rights requests.)

2. Two different roles: when we are the controller, and when we are the processor

We wear two different hats depending on whose data it is and who decided to collect it. Getting this right matters, so we state it plainly rather than describing every activity under a single blanket role:

We act as	For
Controller (India's Digital Personal Data Protection Act, 2023 uses the term "Data Fiduciary" for the same role — see §11)	Account and organisation data, billing and subscription records, website visitor and marketing data, security and audit logs of activity on our own platform, support and sales communications (including the "Ask MESH" chat widget — see §7), and our own business operations generally.
Processor ("Data Processor" under the DPDPA)	Customer Content and Security Assessment Data (§4) — the target URLs, configuration details, evidence, and any personal data incidentally encountered while running a scan or assessment a customer instructed us to run. Here, the customer is the controller and decides what gets scanned, what evidence is kept, and how long it is retained within the limits this policy sets; we act strictly on their instructions. Our processor obligations to customers are set out in our Data Processing Agreement, which forms part of the contract with every customer.

In short: if it's data about you as our customer or visitor, we're the controller and this policy is our own commitment to you directly. If it's data that shows up inside a scan your organisation asked us to run against a target your organisation controls, your organisation is the controller and we process it only as your processor, under your instructions and our DPA.

3. Scope of this policy

This policy covers our role as controller (§2). Our processor obligations for Customer Content and Security Assessment Data are governed by the Data Processing Agreement, which cross-references this policy's retention (§8) and security (§13) commitments rather than duplicating them.

4. What personal data we collect

Category	Examples	Source
Identity & contact	Name, email address	You provide at registration
Account credentials	Hashed password, MFA secret (encrypted)	You provide at registration / MFA setup
Organisation data	Organisation name, plan tier, billing status	You provide; Razorpay/PayPal provide billing status
Payment data	Billing name, email, card last 4 digits	Razorpay or PayPal collect on our behalf — we never see full card numbers
Technical data	IP address (in consent records & audit logs), user-agent string	Automatically collected on pentest consent & login
Usage data	Pages visited, features used, scan history	Automatically collected
Support & sales communications	Support email content; "Ask MESH" chat transcripts (see §7)	You provide
Customer Content and Security Assessment Data (processor role, §2)	Target URLs and domains; HTTP headers and configuration information; bounded evidence snippets and generated reports; uploaded mobile app files (APK/IPA); read-only cloud credentials you supply for a posture check (AWS/Azure/GCP); credentials you supply for an authenticated scan; and any personal data incidentally encountered on your own target while an authorized assessment runs (e.g. a name or email visible in an exposed error page). See the retention table in §8 for how briefly the most sensitive of these are kept — uploaded app files and supplied credentials are the shortest-lived categories on the platform, not the longest.	You add targets and configure scans; our scanners generate findings; you supply credentials directly into a scan configuration form
Integration data (optional, self-service)	Your own Jira API token and Slack webhook URL — encrypted at rest; and, for GitHub, a non-secret App installation ID only (we do not store a GitHub bearer token). Only summary finding data is sent onward via any of these.	You connect these yourself in Account Settings

5. Lawful basis for processing (GDPR Art. 6)

We keep this deliberately simple rather than assigning a basis to every micro-activity. A few corrections worth stating explicitly: authorization to run a security test is not the same thing as GDPR consent to process personal data — it is an instruction under a contract, backed by our legitimate interest (and yours) in verifying that instruction was really given before anything runs. And "contract" is not automatically the right basis when an individual uses the Service through their employer's account — that individual is often not personally a party to our contract with their employer, so we rely on our legitimate interest in operating the account securely for that person's own account activity, not on a contract they didn't sign.

Processing activity	Lawful basis
Providing the SaaS service to an individual acting as their own customer (a sole trader signing up directly, not through an employer account)	Contract — Art. 6(1)(b), directly with that individual
Providing the SaaS service where the customer is a company or other organisation	Contract — Art. 6(1)(b), with the customer organisation, not with any individual team member personally
An individual team member's own account activity within that organisation	Legitimate interests — Art. 6(1)(f) (operating the account they were given access to; not itself a contract with that individual)
Billing and subscription management	Contract — Art. 6(1)(b), or legal obligation — Art. 6(1)(c) for the accounting-record aspect
Executing an authorized scan or pentest engagement once instructed	Contract with the instructing organisation, and legitimate interests in verifying the instruction (RoE/SoW/consent flow) before acting on it — not GDPR consent
Customer Content and Security Assessment Data (§4) processed in our role as processor	Not ours to assign — the customer organisation is the controller and determines the lawful basis for this data; see §2/§3
Security and audit logging on our own platform	Legitimate interests — Art. 6(1)(f) (detecting fraud and misuse)
Regulatory / tax record-keeping (e.g. billing records)	Legal obligation — Art. 6(1)(c)
"Ask MESH" support/sales chat	Legitimate interests — Art. 6(1)(f) (responding to your enquiry)
Marketing communications	Consent — Art. 6(1)(a), separate opt-in, withdrawable at any time
AI-generated remediation suggestions (§7)	An organisation-level configuration choice (a per-organisation opt-in, off by default), not necessarily GDPR consent from any individual data subject — the prompt sent contains no target URL, customer name, or raw evidence (see §7)

6. How we use your data

• To create and manage your account and organisation.
• To run authorized security scans and deliver results.
• To process billing and manage your subscription via Razorpay or PayPal.
• To maintain an audit trail of security-relevant actions (fraud prevention and legal accountability).
• To comply with our Rules of Engagement for penetration testing engagements.
• To send you product updates and security alerts related to your account (transactional emails).
• To respond to support and sales enquiries, including through the "Ask MESH" chat widget.
• To send marketing emails if you have separately opted in.

7. The "Ask MESH" assistant and AI features

Two separate AI-powered features exist. We describe both plainly here because "AI" covers very different data flows depending on which one you mean.

"Ask MESH" — the support/sales chat widget on our site. Messages you type are sent to OpenRouter, Inc., which routes the request to an underlying model — currently OpenAI's gpt-4o-mini as the primary model, with Anthropic's claude-3.5-haiku configured as an automatic fallback if the primary is unavailable. So a given conversation may be processed by either OpenAI or Anthropic depending on availability at that moment, with OpenRouter acting as the routing intermediary for both. We do not inject your account email, name, organisation, or scan data into what the assistant sees — the model only sees what you type, plus static product-knowledge content we've written. Before your message reaches OpenRouter or is stored, we strip out card-number-shaped values, SSN-shaped values, private-key blocks, and password/API-key-shaped text you might paste by accident — this does not extend to your email address or name, since the assistant needs those to open a support ticket if you ask it to. Conversations are retained for 90 days, then deleted by an automated job. Whether OpenRouter, OpenAI, or Anthropic use chat inputs to train their own models is governed by their respective data-use terms, not by anything we control from our side — many API-tier agreements (distinct from consumer chat products) contractually exclude training use, but we are not in a position to independently guarantee what each provider's current policy says, and recommend checking their published terms if this matters to you.

AI-generated remediation suggestions — a separate, optional feature. This calls OpenAI and Anthropic directly (not via OpenRouter), and only when an organisation has explicitly opted in on top of a platform-wide default-off setting. The prompt sent contains only a check identifier and a severity label plus static remediation guidance we've already written — never an affected URL, domain name, customer name, or raw scan evidence. The output (generic remediation text for a given check type) is cached and reused across customers; it does not contain personal data and needs no separate retention period.

8. Data retention

One consolidated schedule, rather than periods scattered across several documents. Every period below is enforced by an automated job unless marked otherwise — none of these are aspirational.

Data category	Retention period
Active user accounts, after cancellation	30 days, then deletion (or immediately on a self-service or admin-actioned deletion request, after a 7-day cancellable grace period)
Scan records & findings	2 years from scan date
PoC / evidence artifact files	90 days
Uploaded mobile app files (APK/IPA)	Deleted immediately when the scan completes or fails — not held for any retention window at all
Read-only cloud credentials, authenticated-scan credentials	Never written to the database — held only in-memory for the single scan run, then discarded
"Ask MESH" chat transcripts	90 days
Security audit logs	3 years
Pentest authorization & consent records	5 years from the end of the authorized engagement window
Billing records	For the period required by applicable tax, accounting and corporate law, including applicable statutory retention periods (currently no less than 8 years, reflecting the Companies Act, 2013 requirement to keep books of account for the 8 financial years preceding the current one)
Revoked API keys	90-day grace period, then hard deletion
Application/server log files	30 days
Consent-record IP addresses	Truncated to a /24-equivalent range after 90 days — kept only to a country/region level of precision beyond that point
Session cookies	Up to 30 days, or until you sign out
Infrastructure backups	7 days (attached-disk backups on the database server; see §15 for what this does and doesn't protect against)

Integration credentials you connect yourself (Jira API token, Slack webhook URL) are kept encrypted for as long as the integration stays connected, and deleted immediately when you disconnect it — there is no separate retention window, because it's your own credential and your own choice when to remove it.

9. Service providers, subprocessors and other recipients

We share personal data with the following recipients where necessary to deliver the Service. Not every recipient below acts in the same legal capacity: most act as our processor/subprocessor for the specific data we send them, but a payment provider may also act as an independent controller for its own fraud-prevention, compliance, or payment-network processing — we list them together here for transparency about where data flows, not to claim a single uniform role for all of them.

Recipient	Purpose	Location
Google Cloud Platform	Hosting, database, file storage	EU (Frankfurt, Germany)
Google LLC (Google Analytics / Google Tag Manager)	Website usage analytics (§14) — acts as an independent controller for certain aggregated Google-side processing, in addition to our instructions	USA / global
Razorpay Software Private Limited	Payment processing & billing (India-based customers) — also acts as an independent controller for its own fraud-prevention and regulatory obligations	India
PayPal, Inc.	Payment processing & billing (customers outside India) — also acts as an independent controller for its own fraud-prevention and regulatory obligations	USA
Zoho Corporation	Transactional email delivery	India
OpenRouter, Inc. (and, transitively, OpenAI / Anthropic as underlying model providers)	"Ask MESH" support/sales chat widget (§7)	USA
OpenAI / Anthropic	AI-generated remediation suggestions (§7) — called directly, a separate path from Ask MESH above	USA
Atlassian (Jira)	Issue tracking (optional, customer-configured integration)	Australia / USA
Slack Technologies	Notifications (optional, customer-configured integration)	USA
GitHub, Inc.	PR status checks (optional integration)	USA

On transfer mechanisms — stated accurately rather than assumed: where a recipient above is located outside the jurisdiction the personal data originates from, we expect the applicable safeguard to be that provider's own published data processing addendum or standard contractual terms, which each of the providers above makes available to its customers. We have not independently verified, provider by provider, that each such addendum has been contractually incorporated into our arrangement with them, so we do not represent that we are already bound by every published term as a matter of course. If you are a customer who needs to confirm the specific instrument in place for a given provider (for your own compliance records), contact support@breakmesh.io and we will check and point you to the relevant terms.

Our own operating company, Alphasoft Infotech Private Limited, is based in India. India does not currently hold an EU adequacy decision. Production data is hosted in the EU (Frankfurt) and India-based staff do not have access to the production database — only to a separate test environment (see our Trust page). Where any remote access to production data by India-based personnel does occur (for example, through the administrative interface for support purposes), whether that access constitutes an international transfer under GDPR Chapter V depends on the circumstances — regulatory guidance distinguishes access by personnel who are an integral part of the same controller/processor from access by a genuinely separate importer, and we have not yet had that specific data flow assessed against that distinction. Where applicable law requires a transfer mechanism for this or any other flow described in this section, we use the appropriate contractual or other legally recognised safeguard; for data where a customer organisation is the controller and we act as their Indian processor, the applicable mechanism is addressed in our Data Processing Agreement, not asserted here.

We will give 30 days' notice before adding any new sub-processor that processes personal data.

10. EU/UK representative

As stated in §1, we do not currently market the Service to EU or UK residents, and have not appointed a representative under Art. 27 GDPR / UK GDPR. If you are an EU or UK resident who subscribes to the Service independently, without our marketing having been directed at you, mere accessibility of our website from the EU/UK is not by itself enough to bring us within Art. 3(2)(a) GDPR's "offering of goods or services" test (per EDPB Guidelines 3/2018 on "targeting").

That is a separate question from Art. 3(2)(b) (monitoring the behaviour of individuals in the EU/UK), which does not require an intention to target and can, depending on the purpose and any subsequent analysis, be engaged by online tracking through cookies. We use Google Analytics on our website (§14), so we do not state as broadly as an earlier version of this policy did that an independently-arriving EU/UK visitor is necessarily outside GDPR's territorial scope. More accurately: we do not currently direct our commercial offering to the EU/UK, but whether GDPR/UK GDPR applies to particular processing depends on the circumstances, including any applicable offering-of-services or monitoring criteria under Art. 3(2). We intend to appoint representatives in both jurisdictions before actively marketing there.

11. India — Digital Personal Data Protection Act, 2023

As an Indian company, we are also subject to India's Digital Personal Data Protection Act, 2023 ("DPDPA"). The DPDPA is being brought into force in stages: under the notification issued 13 November 2025, most of its operative data-processing obligations take effect eighteen months from that date, with a smaller set of provisions already in force earlier. We are aligning our practices with the DPDPA's core principles — notice, consent for processing that requires it, purpose limitation, data minimisation, reasonable security safeguards, and a grievance-redressal mechanism — ahead of that full commencement timeline, rather than waiting for it, so this policy should not need a second major rewrite once the remaining provisions phase in.

Under the DPDPA, our role as described in §2 corresponds to "Data Fiduciary" (controller) or "Data Processor" as applicable, and you are a "Data Principal" (data subject). Our designated Grievance Officer contact for DPDPA purposes is support@breakmesh.io — the same address that already handles data-subject-rights requests under §12.

12. Your rights

Where GDPR or UK GDPR applies (see §10), you have the following rights regarding your personal data:

• Right of access (Art. 15) — request a copy of all data we hold about you via your account settings or by emailing support@breakmesh.io.
• Right to rectification (Art. 16) — correct inaccurate data in your account settings.
• Right to erasure (Art. 17) — request deletion of your account and data. Use the "Delete account" option in Settings or email us.
• Right to restrict processing (Art. 18) — request that we pause processing of your data while a dispute is pending.
• Right to data portability (Art. 20) — download a machine-readable JSON export of your data via Settings.
• Right to object (Art. 21) — object to processing based on legitimate interests, including direct marketing.
• Right to withdraw consent — withdraw marketing or AI-remediation consent at any time via account settings.

When the relevant provisions of India's DPDPA (§11) commence, you will separately have the rights the DPDPA itself provides for a Data Principal — these are not simply a relabelling of the GDPR list above. They include access-related rights (a summary of your personal data and the processing activities carried out on it), correction and erasure of your personal data, a right to grievance redressal, and a right to nominate another individual to exercise your rights in the event of death or incapacity. We will publish how to exercise these, and our grievance procedure, as those provisions come into force.

We aim to respond to rights requests within the period required by applicable law (for example, GDPR's one-month period, extendable in specified circumstances). If a request can't be completed by an in-app self-service action, our support team (not just an automated process) can also action it on your behalf — see the admin-triggered path described for exactly this purpose.

If you believe your rights have not been respected, you may lodge a complaint with your national data protection supervisory authority. In the UK, this is the Information Commissioner's Office (ICO).

13. US privacy rights

We keep this section short because it can be: we do not sell personal information, do not share it for cross-context behavioural advertising, and do not run targeted advertising of any kind — our only analytics are Google Analytics and Google Tag Manager for aggregate site usage (see our Cookie Policy), and we have no ad-network or data-broker integration anywhere in the product. Where California's CCPA/CPRA or another US state privacy law applies to you, you have rights to know/access, delete, and correct your personal information, and to opt out of any sale or sharing of it (moot here, since we do none) — exercise any of these by emailing support@breakmesh.io.

14. Cookies

We use Google Analytics (GA4) and Google Tag Manager for website usage analytics. Google Analytics uses first-party analytics cookies (normally _ga and _ga_<container-id>, set on our own domain) and sends analytics information — including a pseudonymous client identifier, and device/browser and interaction information — to Google, which Google then aggregates into reporting; it is not, itself, a pre-aggregated feed. So we do not claim to use only strictly-necessary cookies. We do not run advertising or cross-site behavioural tracking of any kind. See our Cookie Policy for the full list of cookies, what each one does, and how to control them.

15. Security

We implement technical and organisational measures appropriate to the data we hold, including password hashing, encrypted storage of secrets and integration credentials, TLS in transit, HSTS, and hardened session-cookie flags. We deliberately do not list specific algorithms or parameters here — those live on our Trust page instead, so that an internal engineering change (e.g. a stronger hashing scheme) never leaves this legal document describing something we've already moved past.

16. Children

The BreakMesh platform is not intended for use by individuals under the age of 18 — enforced by a required confirmation checkbox at signup, not merely stated. We do not knowingly collect personal data from children.

17. Changes to this policy

We will notify registered users by email at least 14 days before any material change takes effect. The current version and effective date are shown at the top of this page. This notice explains how we handle your data — it is not itself something you accept by continuing to use the Service; where your consent is legally required for a particular activity (marketing, optional AI features), we collect it separately and specifically for that activity, not by inference from continued use.

18. Contact

Data controller / Data Fiduciary: Alphasoft Infotech Private Limited, trading as BreakMesh
Registered office: 11, Vrindavan Shilp Apt, S. No. 30/34, Pipe Line Road, Nashik, Maharashtra, India, 422001
Email: support@breakmesh.io