Draft pending legal review. This text is being finalised with counsel and the highlighted values are not yet filled in. It is published so you can read exactly how we say we behave, and hold us to it.

SecQon Privacy Policy

Effective date: 31 August 2026 · Version: 2026-08-v1

This policy describes how Infiqon Private Limited (CIN COMPANY_CIN), registered office REGISTERED_ADDRESS ("Infiqon", "we", "us"), handles personal data in connection with SecQon — the service at secqon.com, its API, and the free exposure check on our home page.

It is written to be checkable. Every claim below describes something the code actually does; where a decision has not been made yet, or where only the owner of the company can supply the value, you will see a highlighted placeholder in double square brackets rather than a comfortable sentence. A privacy policy that describes processing we do not perform is worse than no policy at all, because it is the document people rely on when deciding whether to trust us.

This policy forms part of the Agreement (Terms of Service, Section 10.1).

1. The two roles we play

Data protection law asks whose data you are handling and on whose instructions. SecQon does both, and the difference decides your rights.

1.1 We are the Data Fiduciary — under India's Digital Personal Data Protection Act, 2023 (the "DPDP Act") — for the personal data we decide the purposes for ourselves: your account details, the addresses of people you invite, what a visitor does on our marketing site, and our billing and security records.

1.2 We are a Data Processor for Customer Data — the assets you add, the scans you run, the Findings, evidence and Reports they produce. We process it on your instructions to deliver the Service, and nothing else. If your Findings contain personal data — an email address in a response body, a name in a page we fetched from your own site — you are the fiduciary for it and we handle it under Terms of Service Section 9.

1.3 We are not an adtech company. We do not sell personal data, we do not share it with data brokers, and we do not use Customer Data to train a language model. Section 5 states precisely what leaves our systems and reaches a model.

2. What we collect, and when

Anyone can enter a domain on our home page and get a passive snapshot. For each run we write one record containing:

the host you entered, and whether it answered at all;
the exposure score, grade and finding count we showed you, and the short teaser list of finding titles;
click attribution, if the URL carried it — utm_source, utm_medium, utm_campaign, utm_term, utm_content, gclid, msclkid and the referring host. This is an allowlist, not "whatever is in the query string", so an ad platform adding a parameter cannot turn a public endpoint into an open bucket for arbitrary text;
a keyed digest of your IP address — not the address itself. It is enough to spot a burst of automated checks from one source, and not enough to re-identify you or to hand anyone a list of who scanned what.

Your email address is not part of that record. It is stored only if you then ask us to send you the full result, and only the first address submitted against a check is kept. That endpoint cannot be used to read a result back out, so it cannot be used to discover who checked which domain.

2.2 Creating and running an account

Account: your email address, a password, and your company name. The password is stored only as an argon2id hash. We never hold it in a form we could read, which also means we cannot tell you what it is.
Your team: the email address and role of anyone you invite, and who invited them.
Your assets: the domains, subdomains, IP addresses and API endpoints you add, the verification token we issue for each, and the result of every verification attempt.
Scans and Findings: scan records, and each Finding with its evidence — which is captured from your own systems: the request we sent, the response we received, and the reasoning that produced the verdict.
Reports and share links: the frozen report, and the fact that a share link exists. The share token itself is a credential and is never written to an audit record.
Alert rules: the destination you configure — an email address, a Slack incoming-webhook URL, or your own HTTPS endpoint.
API keys: a key's non-secret prefix and a hash of it. The key itself is shown once, at creation, and never stored in a form we can read back.

2.3 Credentials you choose to give us

If you supply credentials so a scan can test an authenticated area of your own application, they are encrypted at rest, decrypted only in the moment a scan uses them, and never written into a Finding, a Report, an audit record or a prompt. They are the one category of data we hold that we treat as irrecoverable by design: you can replace or clear them, and we cannot show them back to you.

2.4 Paying for a plan

Paid plans are sold through INFIQON Billing, our group billing service, which is the merchant of record and issues your GST invoice. At checkout you give it your billing country, your state code or GSTIN, and your billing address, so the correct tax treatment can be applied.

We never see your card. Checkout is hosted by INFIQON Billing on infiqon.com; a card form served from secqon.com is refused. No card number, expiry or CVV ever reaches SecQon, and none is stored by us in any form.

2.5 Security, audit and legal records

Legal acceptance records. When you accept the Terms, the Acceptable Use Policy or the Rules of Engagement, we record which document, which version, a SHA-256 of its exact text, your user and organisation, the timestamp, your IP address and your browser's user-agent string. This is deliberate: those two fields are the evidence that a specific person authorised live testing of a specific system, and without them the authorisation record proves nothing.
Audit log. Every authorisation-relevant action — accepting an agreement, adding or removing an asset, verification results, scan attestations, scans starting and finishing, scope-guard denials, issuing and revoking a report share link or an API key, password resets, admin overrides and the kill switch — is written to an append-only, hash-chained log that cannot be edited after the fact.
Operational logs. Ordinary server and request logs kept for reliability, abuse prevention and security investigation.

Our marketing site can load Google's analytics and conversion tag. It is injected only after you have granted consent in the banner — not blocked after loading, not loaded "pending" a choice. Decline, or simply never answer, and no tag is loaded and no analytics identifier is set. Your answer is stored in your own browser under secqon_analytics_consent, and you can change it by clearing your site data.

We are an Indian company selling to buyers who are themselves accountable for their vendors' behaviour. A security vendor that quietly fingerprints its own landing page is not one anyone should trust.

2.7 Browser storage inside the app

The signed-in app keeps your session token in your browser's localStorage, and your analytics choice alongside it. Both live on your device, not in a third-party cookie, and are cleared when you log out or clear site data.

3. Why we process it

The DPDP Act asks us to state the purpose, so here it is in full:

To provide the Service you asked for: verify your assets, run the scans you authorise, produce Findings and Reports, and notify you.
To keep testing lawful and bounded: the ownership gate, the scope guard, rate limits and the audit trail all depend on the records above.
To bill you and issue a compliant tax invoice.
To secure the platform and investigate abuse of a public endpoint.
To measure our own funnel — how many exposure checks ran, how many became accounts — which is why an attribution record exists at all.
To answer you when you write to support, and to send transactional email.

Our lawful basis is your consent — given when you create an account, submit your address for a result, or accept the analytics banner — and, for the security, billing and audit records, the legitimate uses the DPDP Act recognises for performing a contract and complying with law.

4. Marketing email

If you gave us your address to receive the full result of a free exposure check, we may write to you about SecQon. Every such message carries an unsubscribe instruction, and withdrawing consent is honoured on the address, not merely on the campaign. Transactional email — password resets, team invitations, scan reports, monitoring alerts — is part of the Service and is not marketing.

5. What reaches a language model — the specific answer

This is the question every security buyer asks, so here is the mechanism rather than a reassurance.

5.1 The provider. Google Vertex AI (Gemini), in the asia-south1 region. That region is pinned in configuration, and it is the same region the rest of the platform runs in, so prompt data does not leave India in the course of ordinary use.

5.2 What is sent. Only normalised Finding fields — title, category, severity, the OWASP or CWE mapping, and short evidence snippets that have been summarised and redacted first. Never a raw tool dump. Never a full request/response body. Never a credential you supplied.

5.3 Two layers, not one. The payload is minimised by construction, and then every string is passed through a redactor that strips the common secret and personal-data shapes — authorization headers, bearer and basic tokens, API keys, private key blocks, JWTs and provider key prefixes — before it can be placed in a prompt. Minimisation is the rule; redaction is the safety net for when the rule is imperfect.

5.4 Sometimes no model is called at all. The free exposure check makes no model call. The Free plan and the Light scan profile have a per-scan model budget of zero, and fall back to rule-based text. The Security Questionnaire Pack is derived entirely from your own scan data; a model may only rephrase wording, never supply a fact.

5.5 No training. Your Findings, evidence and Reports are not used to train or fine-tune any model, ours or a provider's.

6. Where it is processed, and where it goes

6.1 Hosting. Google Cloud Platform in asia-south1 (Mumbai): the application on Cloud Run, the database on Cloud SQL for PostgreSQL, secrets in Secret Manager. Findings and their evidence live in that database, inside your own tenant's rows.

6.2 Scan traffic leaves from our controlled egress range and is directed only at assets you have verified. What we send to your systems is governed by the Rules of Engagement, not by this policy.

6.3 Transfers outside India. Two of our processors may handle data outside India: our transactional email provider (which necessarily receives the recipient address and the message) and, for payments, INFIQON Billing and its payment gateway. The current list, with each processor's location, is published at SUBPROCESSORS_URL. We will give notice before adding a processor that handles Customer Data.

7. Who else sees your data

Google Cloud Platform — hosting and database, asia-south1.
Google Cloud Vertex AI — model inference on redacted, minimised findings, asia-south1.
Mailtrap — transactional email delivery (password resets, invitations, reports, alerts).
INFIQON Billing, and Razorpay as its payment gateway — subscriptions, payments and GST invoicing. INFIQON Billing is the merchant of record.
Google Analytics and Google Ads — only if you granted analytics consent.

And, by your own action rather than ours:

anyone you give a report share link to can read that Report;
anyone you invite to your organisation can see its assets and Findings;
your Slack workspace or webhook endpoint receives alert content if you configure an alert rule pointing at it.

We disclose data to anyone else only where compelled by law, and in that case we will tell you unless we are legally prohibited from doing so.

8. How long we keep it

8.1 Your account and Customer Data are kept for as long as your account exists. On termination you may export your Reports for 30 days, after which we may delete Customer Data (Terms, Section 9.6).

8.2 The audit log is not deleted while the account exists. It is append-only by design — it is the record of who authorised live testing of a system, and a deletable authorisation record is not evidence of anything. It holds actor identifiers and IP addresses, not Findings.

8.3 Free exposure checks and the addresses attached to them are retained for LEAD_RETENTION_PERIOD, then deleted.

8.4 Honesty about the mechanism. Retention is enforced by hand today, not by a scheduled job. When you ask us to erase something we do it and confirm; we do not want you to believe an automated deletion runs that does not.

9. Your rights under the DPDP Act

As a Data Principal you may:

ask what we hold about you and how it has been shared;
have it corrected where it is inaccurate or incomplete;
have it erased, where we are not required to keep it for a legal, contractual or audit reason;
withdraw consent you previously gave — as easily as you gave it;
nominate another person to exercise these rights if you are unable to;
complain, first to us and then to the Data Protection Board of India.

To exercise any of these, write to PRIVACY_EMAIL. We will respond within 30 days. If your data reached us because someone added you to their SecQon organisation, we will point you at that organisation, because they are the fiduciary for it and we act on their instructions.

Grievance Officer: GRIEVANCE_OFFICER_NAME, GRIEVANCE_EMAIL.

There is no self-service "delete my account" button in the product today. A deletion request is carried out by a person, which is why the address above is the route rather than a control we have not built.

10. How we protect it

Passwords hashed with argon2id; scan credentials encrypted at rest and decrypted only in use.
Tenant isolation on every read: a record is fetched only within the organisation that owns it.
The audit log is hash-chained with a keyed HMAC, so an edit or a rewrite is detectable even by someone with write access to the store.
Secrets held in Secret Manager, never in the repository, never in a browser bundle.
TLS in transit; least-privilege service accounts; the evidence store is private with public access prevention enforced.

No system is perfectly secure, and we will not pretend otherwise. If you find a weakness in ours, tell us at SECURITY_EMAIL — we would rather hear it from you.

11. If something goes wrong

If a personal data breach occurs we will notify the Data Protection Board of India and every affected Data Principal, in the manner and within the time the DPDP Act requires.

12. Children

SecQon is a business service and is not directed at children. You must be 18 or older to create an account. We do not knowingly process a child's personal data; if we learn that we have, we will delete it.

13. Changes to this policy

This document carries a version identifier and a SHA-256 hash of its exact text, both published on the page you are reading. We will post a new version here and, for a change that materially affects your rights, notify you by email before it takes effect.

14. Contact

Infiqon Private Limited · REGISTERED_ADDRESS

Privacy and data rights: PRIVACY_EMAIL · Grievance Officer: GRIEVANCE_OFFICER_NAME, GRIEVANCE_EMAIL · Legal: LEGAL_EMAIL · Security: SECURITY_EMAIL · Abuse and emergency stop: ABUSE_EMAIL · Support: support@secqon.com