SecQon Privacy Policy

Effective date: 14 October 2026 · Version: 2026-10-v12

This policy describes how Infiqon Private Limited (CIN U62090UW2026PTC251250), registered office Plot No. 20, Block H-1/A, Sector 63, Noida, Gautam Buddha Nagar 201301, Uttar Pradesh, India ("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

2.1 The free exposure check — no account, no signup

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 (Google Ads), msclkid (Microsoft Ads), li_fat_id (LinkedIn Ads) and the referring host, with the page you first landed on and a yes/no for whether you arrived from an ad. 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.
• Where you first came from: when you sign up, the first-touch record from your browser (Section 2.8): the campaign parameters and referring host, the ad platform's click id if there was one (gclid, msclkid or li_fat_id, Section 2.1), the page you landed on and whether you arrived from an ad. It is stored with your account and used to credit a later purchase to the campaign that earned it.

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 by Infiqon Private Limited directly, with Razorpay as the payment gateway. At checkout you give us your billing country, your state code or GSTIN, and your billing address, so that the correct tax treatment can be applied and your payment document can be made out to you. That document is a GST tax invoice (Infiqon's GSTIN is 09AAICI8037N1ZW), and the details you give are printed on it because GST law requires them.

We never see your card. The checkout window is served by Razorpay from checkout.razorpay.com and runs inside Razorpay's own frame on this site. Your card number, expiry and CVV are submitted to Razorpay and never reach SecQon or Infiqon — we receive only the outcome of the payment and the last four digits and card network, which Razorpay reports to us. Nothing of your card 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. They are stored in a log store in asia-south1 and kept for 180 days, which is the period and the location the CERT-In directions of 28 April 2022 require of an Indian service provider; a copy in Google's default log store is kept for 30 days.

2.6 Analytics, advertising measurement, and the consent that gates it

Our site can load Google Tag Manager, and through it three things: Google Analytics 4, which counts visits; Google Ads conversion tracking; and the LinkedIn Insight Tag, LinkedIn's conversion tracking. Tag Manager is a container: it holds the tags rather than being one. 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 container and no tag is loaded, and no analytics or advertising 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.

What we measure. Which of our ads and campaigns led to a free exposure check, an address left against one, an account, a trial and a purchase — so we know which advertising works. We receive counts and aggregated reports. Neither platform tells us who you are.

What Google does. Google Analytics records the pages you view on our site and the conversion events above. Google Ads links a signup or purchase to the Google ad you clicked. Ad personalisation is switched off on the Google tag, so your visit is not used to build an advertising profile of you.

What LinkedIn does — and what it can know. To credit a signup to a LinkedIn ad, LinkedIn recognises the browser through its own cookies and, if you are a LinkedIn member, matches the visit to your LinkedIn account. On our public pages the Insight Tag also records the pages you view and the buttons and links you click, including the text on them. When we tested it, it did not record what was typed into our forms. LinkedIn shows us only aggregated reports. What LinkedIn does with this on its side is governed by LinkedIn's own privacy policy.

Never inside your account. The signed-in app (/app, /admin, /billing) does not run LinkedIn's script: those pages are served with a security policy under which the browser refuses it. When a conversion happens inside the app — starting a trial, paying — it is reported to LinkedIn by a single image request that names which conversion it was and carries none of the page's content. LinkedIn's own cookies go with it, as with any request to LinkedIn.

No retargeting. We build no advertising audiences from visits to our site, on Google or on LinkedIn, and we do not use it to show you ads elsewhere.

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.6.1 Counting we do ourselves

Separately from the tags above, our own server counts what happens on our public pages. This does not go through Tag Manager, and it runs whatever you choose in the banner, because it sets nothing in your browser to identify you and sends nothing to anyone else. This is all of it.

What is recorded. One record for each of these:

• a page you view: its path only, such as /pricing, never the full address and never anything after a ? or #;
• a click on one of a fixed list of buttons: buy, start free, book a call, open the sample report and pricing, plus two moments that are not clicks: the sign-up page being shown, and the payment window being opened;
• how long a page was visible to you. A tab left in the background does not count;
• recorded by our server rather than your browser: a free exposure check being run, an account being created, and a purchase, with its plan, amount and currency.

A page view carries a campaign only on the page you arrive on. When the address you open carries campaign tags (utm_source and the like) or comes from an ad click, that page view records the tags in that address, that page as the one you landed on, and whether you came from an ad. The pages you view after it carry none, and a page view never carries the campaign of an earlier visit. The free checks, signups and purchases our server records carry the campaign you first arrived from instead: its campaign tags, the page you landed on and whether you came from an ad (the secqon_attribution record, Section 2.8). For a purchase, that is the campaign your account was first created from (Section 2.2). Clicks and time on page carry none of it. If another site linked you to us, the first page you open also carries that site's host name, never its full address. An ad platform's click id is never part of these counting records; they keep only the fact that there was one. The free exposure check record (Section 2.1), your account's record of where you first came from (Section 2.2) and the record in your browser (Section 2.8) keep a gclid, msclkid or li_fat_id itself, as before. The other markers Google adds to an ad click (gbraid, wbraid, gad_source) are read only as "came from an ad". They are never stored in a counting record, in your account's record, in the free exposure check record or in the record in your browser. Our ordinary request logs (Section 2.5) keep the address each page was requested at as it was requested, query string included, as they do for every request, so a marker in that address is kept there for as long as those logs are kept.

Never inside your account. Nothing is counted in the signed-in app (/app, /admin, /billing) except a marker that the payment window was opened and, when a payment succeeds, the purchase our server records. Password reset, invitation and email-confirmation links, and any other address that carries a token, are never counted at all.

No cookie, and nothing new that identifies you. This counting sets no cookie and stores no identifier on your device. The only thing it adds in your browser is two entries in the secqon_attribution record that was already there: the page you landed on, and whether you came from an ad. It also writes that record when you arrive from an ad click that carried no other campaign tag, where before nothing would have been stored.

Telling one visit from another, for one day only. To know that three page views came from one person rather than three, our server works out a code from your IP address and your browser's identification string (its user-agent), using a random key. Every day (UTC) gets its own key: the first time our server records anything on a new day, it makes that day's key and deletes every earlier one. These records hold only the code, never your IP address and never the user-agent string. Once a day's key is gone (from our database once the next day's key is made, and from our database backups and point-in-time recovery logs, which we keep for 7 days, when they expire), the code can no longer be worked out again from an address, and the same person on two different days gets two unrelated codes. These records are not anonymous: a signup record can be matched to the account it belongs to by its time, and a purchase record by its time, plan and amount, and with either, that day's page views. Our ordinary request logs are separate from this and are kept as Section 2.5 describes.

Kept as categories only. Your country, as our network provider (Cloudflare, Section 7) reports it for your connection; your device type: mobile, tablet or desktop; and your browser family, such as Chrome or Safari. Not the version, the operating system or the exact device.

Crawlers are left out. Search-engine crawlers, scripts and other automated tools that identify themselves as such are discarded before anything is stored.

It stays with us. None of it is passed to Google Analytics, Google Ads, LinkedIn or anyone else. Like every request to our site, it reaches us through Cloudflare (Section 7). It is stored in our own database, on the hosting described in Section 6.1, kept for 13 months and then deleted automatically (Section 8.5).

Why. To know which of our pages, campaigns and ads lead to free checks, signups and purchases: the question Section 2.6 asks, answered with figures that do not depend on who accepted the banner.

2.7 Browser storage inside the app

The signed-in app keeps your session token in your browser's localStorage. It lives on your device, not in a cookie, and is removed when you log out. Section 2.8 lists everything we store in your browser.

2.8 Everything we store in your browser

SecQon itself sets no cookies. What it keeps is in your browser's localStorage: it stays on your device, is not sent with every request the way a cookie is, and you can delete it at any time by clearing this site's data. Cookies appear only once you consent to analytics, and they are set by Google's and LinkedIn's tags, not by us — with one exception: using one of our public forms loads Google reCAPTCHA (Section 2.9), which may set a cookie of its own on Google's domain.

The Google and LinkedIn advertising cookies are set by tags inside our Tag Manager container (Section 2.6). The lifetimes of the LinkedIn cookies above are the ones measured on this site on 28 September 2026. If a tag added to the container sets a cookie not listed here, this table is updated when that tag is published.

Paying. Razorpay's checkout window is served from checkout.razorpay.com and may set its own cookies there to process your payment and prevent fraud. They belong to Razorpay and are governed by Razorpay's policies. They exist only because you chose to pay.

2.9 Bot protection on our public forms

Our sign-up, log-in, password-reset and free exposure check forms are protected by Google reCAPTCHA v3. There is no puzzle to solve: when you start using one of those forms, your browser loads Google's reCAPTCHA script, and when you submit, Google gives the form a score for how likely the request is to come from a person rather than a bot. We send that score request to Google from our server with the form's one-time token and nothing else — not your address, not what you typed.

To score you, Google's script collects information about your browser and your interaction with the page — such as your IP address, browser and device characteristics and how the page is used — under Google's [Privacy Policy](https://policies.google.com/privacy) and [Terms of Service](https://policies.google.com/terms), which apply to it. It loads only once you start using one of those forms, it never runs inside the signed-in app, it does not wait for the analytics banner because it protects the form you are about to submit, and it is not used for advertising. A request Google scores as very likely automated is refused, with a message telling you how to reach us if that happens to you by mistake.

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, including the reCAPTCHA check on our public forms (Section 2.9).
• To measure our own funnel — how many exposure checks ran, how many became accounts — which is why an attribution record exists at all, and which of our ads on Google and LinkedIn earned them (Section 2.6); and, from our own counting, which of our pages, campaigns and ads lead to free checks, signups and purchases (Section 2.6.1).
• To answer you when you write to support, and to send transactional email.

Apart from our own counting (below), 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 account, security, billing and audit records, the legitimate uses in Section 7 of the DPDP Act: data you voluntarily provided for a purpose you did not object to (Section 7(a)), and processing required to comply with a law or a legal obligation, including the record-keeping the Information Technology Act, 2000 and the CERT-In directions require.

Our own counting (Section 2.6.1) does not depend on the banner: it runs whatever you answer there, so consent is not its basis. Under the DPDP Act we treat it as a legitimate use under Section 7(a): the IP address and browser identification string the daily code is worked out from are sent to us by your own browser when you open our pages, and for this counting they are used only to work out that day's code, for pseudonymised measurement of how our own service is used. It builds no profile of you, is not shared with any third party, and is never used to contact you or to target you with advertising. Where the GDPR applies, its basis is legitimate interests, as Part A2 of the GDPR and UK Data Protection Addendum states.

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. Four of our processors may handle data outside India: our network provider, Cloudflare, which carries every request to our site and API through a data centre near the person making it; our transactional email provider (which necessarily receives the recipient address and the message); our error-monitoring provider (which receives reports of errors in the service); and, for payments, our payment gateway. So may Google, for reCAPTCHA on our public forms, and — only if you consent in the banner — Google and LinkedIn for analytics and advertising measurement. The current list, with each processor's location, is Section 7 below. We will give notice before adding a processor that handles Customer Data.

6.4 Out-of-band callbacks. On a Deep Scan, one test induces your own server to make a request to a collector we operate at oast.secqon.com, in asia-south1, to confirm server-side request forgery. What arrives is the request your server made — its source address, and the headers its software attached. The collector keeps this in memory only and discards it within one day; the fact that a callback arrived, and the excerpt needed as evidence, is stored with the Finding like any other evidence.

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.
• Cloudflare (Cloudflare, Inc.) — DNS, TLS and the reverse proxy in front of secqon.com and api.secqon.com. Every request to our site, the app and the API passes through it, with your IP address. Your browser's encrypted connection ends at Cloudflare, which opens a new encrypted connection to Google Cloud, so Cloudflare handles what you send and receive, including Customer Data, in transit. It tells us the country of your connection (Section 2.6.1). It is not configured to cache the app or the API. Global: a request is handled at a Cloudflare data centre near the person making it.
• Mailtrap (Railsware Products Studio LLC) — transactional email delivery (password resets, invitations, reports, alerts). Processes in the European Union and the United States.
• Sentry (Functional Software, Inc.) — error monitoring. When something fails in the web app, the API or a scan, it receives the error message and stack trace, the page or API route, the release, and your browser and operating system, and it works out an approximate location (country and city) from the connection without storing the address. It is not sent your IP address, cookies, what you typed or submitted, or any credential, and session recording is off. An error message can incidentally name one of your assets or findings. Processes in the European Union (Germany).
• Razorpay (Razorpay Software Private Limited, India) — the payment gateway: it hosts the checkout window, takes your card details directly, and processes subscriptions, payments and refunds. Infiqon Private Limited is the merchant of record and the seller; there is no separate billing service.
• Google Tag Manager, Google Analytics and Google Ads (Google LLC, global) — only if you granted analytics consent. Tag Manager delivers the other two; it is the only one of the three loaded directly by this site.
• LinkedIn (LinkedIn Ireland Unlimited Company or LinkedIn Corporation, depending on where you are) — the Insight Tag, only if you granted analytics consent, delivered by Tag Manager and never run inside the signed-in app (Section 2.6).
• Google reCAPTCHA (Google LLC, global) — bot protection on our sign-up, log-in, password-reset and free-check forms (Section 2.9).

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 12 months, then deleted.

8.4 Honesty about the mechanism. Retention is enforced by hand today, not by a scheduled job. The one exception is the counting records in 8.5, which our server deletes itself as it records new ones. 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.

8.5 The counting records in Section 2.6.1 are kept for 13 months, then deleted automatically. The first time our server records anything on a new day (UTC), it makes that day's key, deletes every earlier key, and deletes every counting record older than 13 months. On a day when nothing is recorded, nothing is deleted until the next day something is.

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 legal@secqon.com. 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: Sudheer Machani, Director, sudheer@infiqon.com.

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 legal@secqon.com — 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. Separately, and whether or not personal data is involved, we report the cyber security incidents listed in the CERT-In directions of 28 April 2022 to CERT-In within six hours of noticing them, as those directions require of an Indian service provider.

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 · Plot No. 20, Block H-1/A, Sector 63, Noida, Gautam Buddha Nagar 201301, Uttar Pradesh, India

Privacy and data rights: legal@secqon.com · Grievance Officer: Sudheer Machani, Director, sudheer@infiqon.com · Legal: legal@secqon.com · Security: legal@secqon.com · Abuse and emergency stop: abuse@secqon.com · Support: support@secqon.com

15. If you are in the EEA, the UK or Switzerland

The EU GDPR, the UK GDPR and the Swiss data protection act can apply to our processing even though we are established in India. Where one of them does, the GDPR and UK Data Protection Addendum at secqon.com/legal/gdpr applies alongside this policy. Part A of the Addendum states our lawful basis for each purpose in Section 3, your rights under those laws, how to reach us while our EU and UK representatives are not yet appointed, and which supervisory authority you can complain to.