SecQon Data Processing Agreement

Effective date: 28 September 2026 · Version: 2026-09-v4

This Data Processing Agreement (the "DPA") forms part of the SecQon Terms of Service (the "Terms") between you (the "Customer") and Infiqon Private Limited ("Infiqon", "we", "us"). It applies whenever we process personal data on your behalf. Capitalised terms not defined here have the meaning given in the Terms, the Privacy Policy or the Rules of Engagement.

You do not need to sign or return this document. It binds us both through the Terms, which you accept at signup. If your procurement process requires a counter-signed copy, write to legal@secqon.com and we will provide one on these terms.

This DPA states what the product actually does. Where a clause here could be written more favourably to us than the mechanism allows, it is written to the mechanism instead. The Privacy Policy describes the same processing in plain terms and is the more readable of the two; where a fact appears in both, they are meant to say the same thing, and a discrepancy is a mistake we want to hear about.

1. Which of us is which

Throughout, "DPDP Act" means India's Digital Personal Data Protection Act, 2023, and "Data Fiduciary", "Data Processor" and "Data Principal" have the meanings it gives them. Where you are subject to another regime instead, read "controller" for Data Fiduciary, "processor" for Data Processor and "data subject" for Data Principal; this DPA is drafted to satisfy both readings.

1.1 You are the Data Fiduciary — the controller — for Customer Data: the Assets you add, the Scans you run, and the Findings, evidence and Reports they produce. You decide what is tested and why.

1.2 We are the Data Processor for that Customer Data. We process it on your instructions to deliver the Service and for nothing else.

1.3 We are the Data Fiduciary in our own right for data where we decide the purpose: your account details, the addresses of people you invite, our billing and security records, and what a visitor does on our marketing site. That processing is governed by the Privacy Policy, not by this DPA.

1.4 Where the Asset belongs to someone else — you are an agency, MSP or consultancy testing a client's system — you are the processor for your client and we are your sub-processor. Rules of Engagement §6.3 already requires you to warrant that your authorisation from that client extends to the testing you ask us to do. This DPA is the instrument you pass down: your contract with your client must permit engaging us on these terms.

2. What we process, and for how long

2.1 Subject matter and purpose. Providing the Service: testing the Assets you have verified, recording what we observed, validating it, and producing Findings and Reports for you.

2.2 Duration. For as long as your account exists, plus the periods in Section 8.

2.3 Nature of the processing. Collection, storage, structuring, analysis, retrieval, transmission to you, and erasure.

2.4 Categories of personal data. We do not ask you for personal data about third parties, and the Service has no field for it. It arrives, when it arrives, as a by-product of testing your own systems:

1. In evidence. A Finding carries the request and response that produced it. If your application returns an email address, a name, an order reference or a session identifier on the page we fetched, that is captured as evidence, because a Finding without its evidence is an assertion.
2. Behind a login. This is the case worth reading twice. If you supply credentials and enable authenticated testing, the crawler carries your session on every request and therefore reaches pages only a signed-in user can see — dashboards, account pages, record listings. Materially more of your users' personal data can land in evidence than on an unauthenticated scan. That is the point of authenticated testing and it is the cost of it.
3. In credentials. The account you supply for (b). Rules of Engagement §6.3 requires it to be a test account issued for the purpose and not the account of any natural person, which is the control that keeps a real person's credentials out of our systems entirely.
4. In account and audit records. Names, email addresses, IP addresses and user agents of the people on your account, recorded against the actions they took.

2.5 Categories of Data Principals. Your personnel and, incidentally and through (a) and (b) above, the users of the systems you test.

2.6 Special categories. We do not seek them and the Service is not designed for them. If your application exposes them on a page we fetch, they will be in the evidence. Decide accordingly before enabling authenticated testing on a system that holds them.

3. Your instructions

3.1 We process on your documented instructions and nothing else. Your instructions are: the Terms, this DPA, the Rules of Engagement, the configuration you set in the product (the Assets you verify, the profiles you choose, the acknowledgements and standing authorisations you give), and any further written instruction we accept.

3.2 The product is the instruction surface. Adding an Asset, verifying it, running a Scan, storing credentials, granting a standing authorisation under Rules of Engagement §4E — each is an instruction, and each is recorded in the audit log with who gave it and when.

3.3 If an instruction appears unlawful we will tell you rather than perform it, and may suspend the processing concerned until it is resolved.

3.4 We will not use Customer Data to train any model, ours or anyone's. See Section 6.

4. Confidentiality

Everyone at Infiqon with access to Customer Data is bound by written confidentiality obligations that survive the end of their engagement, and has access only where their role requires it. Findings are your Confidential Information under Terms §9.3.

5. Security

5.1 We maintain the technical and organisational measures described in Privacy Policy §10. In summary, and stated so you can verify each one:

• passwords hashed with argon2id; the credentials you store for authenticated testing 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 in Secret Manager, never in the repository and never in a browser bundle;
• TLS in transit, least-privilege service accounts, and an evidence store that is private with public access prevention enforced.

5.2 Scan traffic is separately controlled. What we send to your systems is governed by the Rules of Engagement: a verified-asset allowlist enforced at the egress boundary on every packet, bounded payloads, per-asset rate limits, and a prohibition on destruction, denial of service, persistence and lateral movement that no acknowledgement relaxes.

5.3 We review these measures as the Service changes. We will not weaken them during your subscription.

6. What reaches a language model

6.1 The provider is Google Vertex AI (Gemini), pinned to the asia-south1 region — the same region as the rest of the platform.

6.2 Only normalised Finding fields are sent: 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 or response body, and never a credential you supplied.

6.3 The payload is minimised by construction and then redacted — every string is passed through a redactor that strips 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.

6.4 Some work calls no model at all: the free exposure check, the Free plan and the Light profile.

7. Sub-processors

7.1 You give general authorisation for the sub-processors below. Each is engaged under written terms imposing data protection obligations no less protective than this DPA, and we remain liable to you for their performance. The current list, what each one receives, and a dated record of every change are published at secqon.com/legal/subprocessors.

7.2 The last three rows process visitor data for which we are the fiduciary, not Customer Data: neither the LinkedIn Insight Tag nor reCAPTCHA can run inside the signed-in app, and reCAPTCHA loads only once a visitor starts using one of the public forms. They are listed for completeness.

7.3 Changes. We will give you notice before adding or replacing a sub-processor that handles Customer Data, by email to your organisation's owners and on the sub-processors page. If you reasonably object on data protection grounds within 30 days, tell us at legal@secqon.com; if we cannot offer a reasonable alternative you may terminate the affected Service and receive a pro-rata refund of fees paid for the unused period.

8. Deletion and return

8.1 On termination you may export your Reports for 30 days, after which we may delete Customer Data. On written request during that window we will delete it sooner.

8.2 The audit log is the exception, and we say so plainly. 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 is retained while the account exists and holds actor identifiers, IP addresses and what was authorised — not Findings and not evidence. If you need it removed after closure, write to us and we will tell you what we can and cannot do and why.

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

8.4 How deletion is actually performed. Retention is enforced by hand today, not by a scheduled job. When you ask us to erase something we do it and confirm it. We would rather tell you that than let you believe an automated deletion runs that does not. This sentence will change when the job exists.

9. Assisting you

9.1 Data Principal requests. If a Data Principal approaches us about Customer Data we will not respond substantively; we will refer them to you and tell you promptly. We will give you reasonable assistance — including access, correction and erasure within your own tenant — to meet your obligations under the DPDP Act or other applicable law.

9.2 Assessments. We will give you the information reasonably necessary for a data protection impact assessment or equivalent, to the extent it concerns our processing and is not available to you in the product or the Privacy Policy.

10. Personal data breach

10.1 We will notify you without undue delay after becoming aware of a personal data breach affecting Customer Data, with what we know: what happened, which categories and approximately how many Data Principals and records are involved, the likely consequences, and what we are doing about it. Where we cannot give all of it at once, we will give it in stages rather than wait.

10.2 Where we are the fiduciary, 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.

10.3 Notifying you is not an admission of fault by either of us.

11. Audit and information

11.1 We will make available the information reasonably necessary to demonstrate compliance with this DPA, and will respond to a reasonable security questionnaire once per year.

11.2 Where that is not enough for your regulator or your own obligations, we will agree an audit scope with you. An audit is at your cost, on reasonable notice, no more than once a year unless a breach or a regulator requires otherwise, subject to confidentiality, and conducted so as not to compromise another customer's data or the security of the Service.

12. Transfers outside India

12.1 Customer Data is hosted and processed in asia-south1, and model inference is pinned to the same region, so Customer Data does not leave India in the ordinary course of the Service.

12.2 Three processors may handle data outside India: 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 our payment gateway. Each is listed in Section 7 with its location.

12.3 Where a transfer occurs we will ensure a lawful basis and appropriate safeguards for it.

12.4 If the EU GDPR, the UK GDPR or the Swiss data protection act applies to your processing, the GDPR and UK Data Protection Addendum at secqon.com/legal/gdpr also applies. It adds the terms those laws require, including the Standard Contractual Clauses for transfers to India, and on a conflict it prevails over this DPA.

13. Liability, term and precedence

13.1 This DPA is part of the Terms. The liability limits and exclusions in the Terms apply to it, as one aggregate limit across both and not one per document.

13.2 It takes effect when you accept the Terms and continues while we process Customer Data for you. Sections 4, 8.2 and 13 survive.

13.3 On a conflict about the processing of personal data, this DPA prevails over the Terms. The Rules of Engagement prevail over both on the conduct and scope of testing — what we may send to your systems is a safety question before it is a data protection one.

13.4 Nothing here reduces a right a Data Principal has under applicable law.

14. Contact

Data protection and this DPA: legal@secqon.com Grievance Officer (DPDP Act): as published in the Privacy Policy, §14. Emergency stop and abuse: abuse@secqon.com

Infiqon Private Limited, India.