Privacy Policy

1. Introduction and scope

This Privacy Policy explains how MAGDOX Private Limited ("MAGDOX", "we", "us" or "our") collects, uses, discloses and protects personal data in connection with this website, MAGDOX Code Security (the magdox command-line interface, the MAGDOX MCP server, the hosted dashboard and API) the FDIE firmware platform, its APIs and analysis workers, and related services (together, the "Service"). This Policy constitutes an electronic record under the Information Technology Act, 2000. It applies to visitors to our website, prospective and current customers, and authorised users of either product acting on behalf of a customer organisation. Magdox is the supplier of both products, not the name of a third product or a separate FDIE company.

This Policy is a notice about our processing; reading it or using the Service does not, by itself, give consent to optional processing. The Service is intended for users who are at least 18 years old; see Section 15.

2. Our roles: controller and processor

MAGDOX acts in different roles depending on the data involved:

• As Controller: for account data (Section 4), website enquiries and bookings, plan and billing records and other data we collect about our own customers and website visitors to operate our business, MAGDOX determines the purposes and means of processing and acts as the Data Controller.
• As Processor: for Customer Data (findings, inventories, reports and any code snippets a customer uploads from the magdox CLI, data entered in either dashboard, FDIE firmware images, configuration and extracted artifacts, and any personal data incidentally contained in them), MAGDOX acts solely as a Data Processor on that customer's instructions.

Account data about a customer's authorised users (names, work email addresses, roles, tokens, authentication and audit events) appears in both roles, for different purposes. MAGDOX processes it as controller to operate and secure the Service, bill the customer and meet its own legal obligations; the retention and rights sections of this Policy apply to that use. The same records are also processed as processor when the customer administers its own users in the dashboard, and the Data Processing Agreement (DPA) governs that use, including deletion or return on termination. Neither role permits sale of the data or its use for model training.

For a local Code Security scan without upload, or a customer-operated FDIE installation, analysis data that does not reach MAGDOX stays outside our custody. Account, licence and authorised support information may still be processed. Any support transfer or enabled integration creates its own disclosed processing path. Our processing of Customer Data is additionally governed by our DPA, which is available to customers, including evaluation participants, before processing that requires a DPA begins.

3. Data controller identity

• Entity: MAGDOX Private Limited
• Registered address: St No. 8, Arabinda Nagar, Barbani, Bardhaman, Hindustan Cables, West Bengal 713335, India
• Privacy contact, for questions about how we process personal data: privacy@magdox.io

Privacy and grievance contact. You may raise a grievance directly with our designated contact below. The DPDPA has a phased commencement; our DPDPA Notice distinguishes current commitments from rights taking effect under that timetable:

• Name: Manish Sharma
• Designation: Founder and CEO
• Email: grievance@magdox.io
• Acknowledgement: within 24 hours of receipt
• Resolution: within 15 days of receipt

If you are not satisfied with our response, applicable law may provide a right to complain to a regulator. See our DPDPA Notice for the commencement and escalation qualifications in India.

4. What personal data we collect

Account data. When you create an account, your organisation gives you access or you contact us, we collect information such as your name, work email address, organisation, role and, for customers, billing contact and address. When you create an account yourself, or accept an invitation that creates one, we record that you agreed to the Terms of Service and the Privacy Policy and confirmed that you are at least 18: one record for each, with the version of the document, the time, and one-way hashes of your IP address and browser (user agent), which we still treat as personal data. These records cannot be changed afterwards; they are evidence of the agreement (Section 10). Both products keep the same kind of record when you accept a new version of either document, when you tick the optional box for onboarding emails at sign-up, and when an administrator agrees to automatic renewal at checkout.

Usage and audit data. In MAGDOX Code Security we record authentication events, token creation and use, findings uploads, exports and administrative actions in an audit log, with the IP address and approximate location of each action, so the customer's administrators can review access to their organisation. On this website, unless you allow the optional analytics described below, the only technical data recorded is the request log kept by our hosting provider (IP address, user agent, page requested, timestamp) and the filtered error reports described below, which are used for security and reliability.

Sign-in protection. Neither product uses a CAPTCHA or other third-party bot check. After repeated failed sign-ins, codes or password resets, further attempts are refused for 30 minutes, then the lock clears by itself; no account is ever locked permanently. After 100 wrong second-factor codes in a row, codes are refused for 30 minutes at a time, while recovery codes still work and the organisation's Super Admin can unlock the account. So that other people's failed attempts cannot lock you out, each product keeps a keyed hash of each network you complete sign-in from (the IP address, or the first half of an IPv6 address), not the address itself, for 30 days, and uses it only to recognise your own networks. When an account is locked, unlocked early or recovered with a recovery code, the event and the IP address involved are recorded in the audit log of each organisation the account belongs to, where that organisation's Super Admins and admins can see it; no organisation sees another organisation's events.

Code Security sign-in location. The approximate location (city, region and country) in the audit log comes from the visitor-location headers our edge network, Amazon CloudFront, adds to each request. Where no header is supplied and a location database is configured on our own systems, it is looked up there. For Code Security, IP addresses are not sent to an external lookup service. FDIE may query IPinfo with the sign-in IP address for approximate audit-log location. Neither product requests GPS or precise device location.

Website forms. The contact form collects your name, work email, organization, product interest and message; the newsletter form collects your email address. Both are validated and stored in MAGDOX CRM, our self-hosted customer-relationship system on Oracle Cloud Infrastructure in India. When the contact form is submitted, MAGDOX staff receive an email alert containing the details you entered, and the address entered receives one short confirmation that the message arrived (at most one a day, and never repeating what was written). The newsletter uses double opt-in: the address entered receives one email with a confirmation button, and it joins the list only if that button is pressed; unconfirmed requests are deleted after seven days. When you confirm, we keep the time you asked, the time you confirmed and a keyed hash of the network address that confirmed, as the record of your consent. Email from MAGDOX CRM is sent through Amazon SES in India: from Mumbai, and newsletters and other campaigns from Hyderabad. You can leave the newsletter from the unsubscribe link in any newsletter or by writing to privacy@magdox.io.

Product sign-ups and onboarding emails. When you create a Code Security or FDIE account, after your email address is verified, the product sends your name, email address, organisation, an internal account reference and whether you asked for onboarding emails to MAGDOX CRM. Later plan events (trial, active plan, seats, plan price, cancellation) follow. We use this to manage our relationship with your organisation. Only if you ticked the box "Email me onboarding tips and product news" when you signed up do we send you product news and a short series of onboarding emails about the product you signed up for: one on the day you sign up and others three, five and ten days later; the last asks for your feedback through an optional Zoho Forms survey. Each has a one-click unsubscribe link, which stops all onboarding and marketing email to that address; account and security emails from the product are not affected. When an account is erased, the product asks MAGDOX CRM to delete that product's records about the person, including their website enquiries and the CRM's copy of their billing records. The CRM keeps only a keyed hash of the address, so that the deleted billing records are not copied back from Dodo Payments; Dodo Payments and our accounting records keep what the law requires.

Communications and meetings. We process the details you submit in enquiries, bookings and support correspondence. If you join a video call, the meeting provider processes call audio and video and participation details. Any recording requires advance notice and any consent required by law.

Code Security authentication data. Sign-in runs on MAGDOX's own pages and MAGDOX's own sign-in service, which we operate on our infrastructure in India. It keeps your password only as a one-way hash, and we store session identifiers and hashed CLI tokens to authenticate and protect your account. These are restricted security records, not marketing data.

• Google or GitHub. If you choose to sign in with Google or GitHub, that provider sends us your email address, your name and an identifier for your account with it. Where GitHub does not confirm that an address belongs to you, we send a code to that address before the account can be used. A Google sign-in is accepted only when Google has verified the email address.
• Enterprise single sign-on. If your organisation connects its identity provider, that provider sends your email address and name when you sign in. We accept it only for people the organisation invited, on email domains the organisation has verified. If the organisation also connects SCIM provisioning, its identity provider sends your email address, name, its identifier for you and whether your account is active, and we add, update or remove your membership as the organisation instructs.
• Two-step verification. If you turn it on, we keep the secret for your authenticator app encrypted, send codes by email that expire after ten minutes, and keep your recovery codes only as keyed one-way hashes.

Code Security sign-up protection. We limit how many accounts can be created from one network and how many emails one address receives, and refuse temporary email domains. No third-party bot check runs on sign-up.

Code Security domain verification. When an organisation verifies an email domain for single sign-on, we store the domain, the verification token and the times it was checked. We look up the organisation's public DNS records through the DNS-over-HTTPS services of Cloudflare and Google, and check them again every day; those lookups send only the DNS names being checked. If the record is missing, the organisation's Super Admins and admins receive an email.

Code Security CLI sign-in and licence activation. Signing in from the magdox CLI sends a device name that is shown on the approval page and recorded in your organisation's audit log: from version 1.3.2, "magdox CLI on" followed by the operating system and processor type (for example linux/amd64); earlier versions send "magdox CLI on" followed by the computer's host name. The magdox CLI generates a device key on the machine where it is activated and sends only the public part with the activation key, so access is bound to that device. Access renewal, rule downloads and vulnerability database downloads contact the platform; --offline stops all platform traffic.

Billing data. Plans bought online are sold through Dodo Payments, which acts as merchant of record: it takes the payment, calculates and collects tax and issues the invoice. Your card or other payment details are entered on Dodo Payments' pages and never reach MAGDOX. From Dodo Payments we receive the subscription's plan, seats, status and billing dates, customer and payment identifiers, and each payment's date, amount, currency, status and, for cards, the card network and last four digits, so the people who manage billing (Super Admins, and in FDIE also admins) can see invoices in the dashboard. Enterprise agreements are invoiced directly by MAGDOX; for those we hold the billing contact and address, tax or registration identifiers required on an invoice, purchase order references and the remittance details our bank reports back to us.

Findings and content data. The magdox CLI scans source code on the customer's own machines and never uploads source files. When --upload is requested, it sends findings metadata (rule, file path, line range, fingerprint, severity), requested inventories and run metadata. Code snippets additionally require --include-code and permission on the receiving repository. This is Customer Data: ownership remains with the customer. File paths, branch names or enabled snippets may contain personal data placed there by the customer's developers; it is processed solely to provide the Service.

FDIE firmware and evidence. Hosted FDIE receives the firmware images, configuration and associated artifacts the customer submits for extraction and analysis. It retains available component, runtime, inventory, comparison and reviewer records. Embedded names, emails, strings, credentials and configuration can contain personal data. These remain Customer Data, processed to supply the requested service; they are not metadata-only uploads. To match vulnerabilities, hosted FDIE looks up the names and versions of libraries it finds in the public OSV.dev database, which Google operates; a lookup carries only the package name and version, never the firmware, file contents or account details.

FDIE identity, notifications and diagnostics. We process configured identity-provider claims, authentication factors, roles, session and audit records. If the organisation connects SCIM provisioning, its identity provider sends each person's email address, name, its identifier for them and whether their account is active, and FDIE adds, updates or removes membership as the organisation instructs. With Google Workspace single sign-on, FDIE accepts only accounts that the organisation's Workspace manages. Customer-requested report emails may include attachments sent through Amazon SES in the AWS profile or an expressly configured customer relay; configured webhooks or collaboration destinations receive the selected content. FDIE sends errors, performance traces of pages, requests and background tasks, server profiles and warning-level log messages to Sentry. They carry stack traces, page paths, endpoint names, technical identifiers and, for server events, the internal user identifier; cookies, credential headers, query strings and request bodies are removed. It is not an intentional destination for uploaded firmware or reports.

Code Security integrations. If a customer connects a source-control provider (GitHub, GitLab or Bitbucket) or configures webhooks, the Service posts findings summaries to that customer's pull requests and sends signed event notifications to the addresses the customer chooses. Source-control tokens and webhook signing secrets are stored encrypted.

Code Security AI review. When a user turns on AI review in the CLI and approves the repository on that machine or in CI, the CLI sends redacted code excerpts (the rule and its guidance, the engine's trace and the surrounding lines, with recognised secrets replaced) directly to the AI provider the customer has configured. MAGDOX does not receive these prompts, and provider keys stay in local configuration. That processing is governed by the customer's own agreement with its provider. With --upload, a finding can carry the verdict, confidence, provider and model; the written reason is uploaded only with --include-code, and proposed fixes are never uploaded.

Code Security MCP server. The MAGDOX MCP server runs on the user's machine and runs the installed CLI. It adds no data flow to MAGDOX beyond what that CLI does. In HTTP mode the customer operates the listener and its access token.

Code Security and website error monitoring. When enabled, the API, dashboard and website send filtered errors to Sentry. Events contain fixed failure categories, selected code locations, service and release metadata and timestamps. Raw messages, identities, request bodies, source context and breadcrumbs are excluded, and session replay is disabled. The dashboard also sends performance data: page-load and navigation timings with the page path only, and a session status for release health. The API and the website send errors only. The CLI sends no error monitoring or usage telemetry.

Optional analytics. Only if you allow it, this website and the Code Security dashboard send usage events to PostHog: the pages you view, which links, buttons and forms you use, browser and device type, and a random identifier kept in your browser's local storage. PostHog receives your IP address with each request and derives an approximate location from it. In the dashboard, events also carry internal user and organisation identifiers and the plan, never your name or email address. On-screen text and element attributes are masked, URLs lose their query and fragment, referrers from other sites keep only their domain, and session recording, heatmaps, surveys and feature flags are turned off. Nothing is sent or stored before you allow it; turning it off stops sending at once and clears the identifier on that browser. FDIE asks the same question in its own banner, and you can change the answer in Settings, Data & Privacy. If you allow it, FDIE sends PostHog the pages you view, without query strings, and a few product events (sign-up, checkout started, subscription started, firmware uploaded, analysis completed, report exported) with a random identifier and, once you are signed in, your internal user identifier, plan and role. FDIE collects no clicks or page content, sends its events through its own relay so that PostHog does not receive your IP address, and sends nothing while your browser's Do Not Track setting is on.

Help Improve FDIE. FDIE's Settings, Data & Privacy also offers Help Improve FDIE. Your choice is recorded, with the date, but nothing uses it yet; we will update this Policy before anything does.

5. How we use your data

We use personal data to:

• Provide, operate and maintain the Service, including account creation, authentication, device activation and account management
• Receive requested Code Security findings or FDIE firmware uploads, carry out the corresponding analysis/review workflow, generate reports and exports, and keep the relevant audit trail
• Process plan purchases, renewals, plan and seat changes and cancellations through our payment provider, and manage Enterprise agreements and invoices
• Provide customer support and respond to enquiries and booking requests
• Send administrative and security messages, such as sign-in and verification codes, invitations, notices about an organisation's verified domains and changes to our terms and policies
• Send scan and digest notifications that users choose to receive
• Protect the Service, including detecting abuse, investigating incidents and maintaining backups
• Improve the Service and its analysis, without using Customer Data to train any model
• Where you allow it, measure which pages and controls of this website, the Code Security dashboard and FDIE are used

6. Why we process your data

Where the GDPR or UK GDPR applies, we use the following bases according to the purpose and the individual relationship:

• Contract: to perform a contract with you or take steps you request before entering it. Where the customer is your employer, routine business contact and account administration may instead rely on our legitimate interests in serving that organisation.
• Consent: for optional communications, analytics on this website, the Code Security dashboard and FDIE, or storage technologies where required. Withdrawal is available without affecting earlier lawful processing.
• Legitimate interests: to operate and secure the Service, prevent abuse, manage business relationships and improve reliability, balanced against individuals' rights. You may object to this processing.
• Legal obligation: to meet applicable requirements, such as statutory recordkeeping. A request from an authority is assessed against the applicable law; it does not automatically authorise disclosure.

These GDPR bases are not interchangeable with the grounds available under other laws. In India, applicable requirements must be assessed under the law in force; when the DPDPA's substantive processing provisions commence, processing must rely on consent or a permitted legitimate use under that Act. See the DPDPA Notice.

Required information. To create an account you must give your name, your email address and, when you create an organisation, its name, and a password unless you sign in with Google, GitHub or single sign-on; you must also accept the Terms of Service and the Privacy Policy and confirm that you are at least 18. An organisation name may not contain a web link or an email address. Without these we cannot provide the Service. Other information is optional unless a form marks it as required.

7. Cookies and tracking

Both products use session and security cookies and the product-specific storage described in the Cookie Policy. This website's own code sets no cookies and loads no advertising or marketing trackers. Optional PostHog analytics run on this website, in the Code Security dashboard and in FDIE only after you allow them, and use browser storage rather than cookies. The Cal.com booking integration loads on the Contact page and when you open a scheduling popup elsewhere. It may use provider cookies or storage for scheduling and security. The contact and newsletter forms post to this website, which passes the details to MAGDOX CRM, our own customer-relationship system hosted on Oracle Cloud in India. Links in MAGDOX CRM emails (unsubscribe and newsletter confirmation) open pages on crm.magdox.io that set no cookies. Cloudflare may set security cookies or storage depending on the protection features enabled, including the Turnstile check on the website's forms, without an interactive challenge. See the Cookie Policy for the inventory and browser controls. The analytics choice covers PostHog only; it is not a statement that third-party requests or storage never occur.

Do Not Track. No uniform technical standard for Do Not Track browser signals exists, so apart from one case we do not respond to them: FDIE's optional analytics send nothing while the signal is on. If a standard is adopted that we are required to follow, we will update this Policy.

Global Privacy Control. We do not sell personal data or share it for cross-context behavioural advertising. GPC signals concern those uses, not the service-provider disclosures described below. Any future change would require an updated notice and applicable opt-out controls before it begins.

8. Sharing and sub-processors

Amazon Web Services hosts both products: application compute, storage, Magdox-operated identity, analysis compute, backups, security monitoring and edge delivery; Amazon SES handles transactional/security email, requested report delivery and MAGDOX CRM's email. Cloudflare provides DNS (for the product addresses DNS only, so product traffic does not pass through it), Turnstile bot checks on the website's forms, the separately operated marketing website, and the network in front of MAGDOX CRM's public address (crm.magdox.io), which carries the CRM's email links and forms and the messages the products and this website send to the CRM. Other disclosed providers include MAGDOX CRM (self-hosted on Oracle Cloud Infrastructure in India) for enquiries, support, opted-in newsletters, and the billing contacts and contract records of agreements we bill directly, Zoho for our @magdox.io mailboxes, the optional feedback survey and our accounting records, Cal.com for appointments, Zoom for meetings, Sentry for diagnostics, PostHog for optional analytics only after you allow them, and IPinfo for FDIE sign-in location. Dodo Payments is merchant of record and an independent controller for online sales, not a customer-data subprocessor. The provider register specifies the purpose, location, role and migration boundary for each service; replacing transactional email does not change where business-contact records are held.

Amazon SES receives the recipient address, message content and delivery metadata necessary to send requested mail. Bounce and complaint feedback supports suppression and abuse prevention; both products keep a hash of each suppressed address, not the address, and it is treated as personal data. Customer-requested report attachments and onward recipient mail systems have a separate disclosure boundary from hosted firmware storage.

GitHub, npm and Homebrew distribute the CLI and the MCP server. They see ordinary download requests from the people who install them and receive no customer content from MAGDOX. Source-control providers, webhook destinations and AI providers that a customer connects are the customer's own choices, not MAGDOX sub-processors. Google and GitHub, when you choose to sign in with them, and an organisation's own identity provider act under their own terms; they confirm who you are to us and receive no customer content from MAGDOX. Google's public DNS service receives only the DNS names we look up for domain verification. Google's OSV.dev vulnerability database receives the library names and versions that hosted FDIE looks up (Section 4), and no personal data.

We may also disclose personal data to professional advisers, regulators or courts where legally required. We do not sell personal data, and we do not share personal data for cross-context behavioural advertising.

Notice of new sub-processors. Before engaging a new sub-processor that will process personal data on behalf of customers, including evaluation customers, we will provide at least 14 days' advance notice by posting an update to the sub-processor list in our DPA and by email to the affected customer's designated contact. If you reasonably object to a new sub-processor on data protection grounds, contact privacy@magdox.io within that notice period and we will work with you in good faith to address the objection, which may include making a commercially reasonable alternative available.

Business transfers. If MAGDOX is involved in a merger, acquisition, financing or sale of all or substantially all of its assets, personal data may be transferred as part of that transaction. We will notify you before your personal data becomes subject to a different privacy policy as a result.

9. International data transfers

This edition describes the AWS hosting profile that Code Security and FDIE have run on since 5 October 2026. Existing signed orders and processing terms continue until validly changed. Confirm the profile for your organisation before relying on a location, retention period or recovery objective.

For the AWS shared-hosting profile, MAGDOX Code Security and FDIE product databases, customer-content object storage, identity records and regional backups are configured in India. This is not an all-processing residency promise: CloudFront operates globally and global-service records can be processed in the USA. CloudFront and its web firewall can write their logs only in the USA (AWS us-east-1); we keep them there for 14 days and keep a copy in India for 180 days. The access logs hold no IP address, cookies or query strings; the firewall logs cover only requests it blocked or flagged, with credentials and query strings removed. Sentry and PostHog (only when analytics are allowed) process in the USA; IPinfo, Google's OSV.dev service, Dodo Payments, recipient mail services and customer-selected providers have their own locations. Any retained marketing-site or integration use of Cloudflare has a global processing boundary.

Amazon SES sends from India: from Mumbai, and MAGDOX CRM's newsletters and other campaigns from Hyderabad. Onward email delivery and recipient systems can process message content elsewhere. Dedicated and customer-operated deployments have separately agreed locations. The standard AWS profile does not include a second-region database/object recovery copy; a different recovery location requires review, notice and any applicable transfer safeguards before use.

Where required for a restricted transfer, the parties must put an applicable transfer mechanism in place before that transfer: for example, the EU Standard Contractual Clauses with the appropriate module and completed annexes; the UK IDTA or EU clauses with the UK Addendum; or clauses adapted for Swiss law. Required transfer assessments and supplementary measures are part of that process. Acceptance of the Terms of Service or this public notice does not itself complete a transfer agreement. Contact privacy@magdox.io for the safeguards applicable to your engagement and a copy, subject to appropriate redactions.

10. Data retention

• Ordinary account data is retained for the duration of your contract plus a 90-day post-contract window before scheduled deletion begins, subject to earlier valid deletion instructions. Statutory billing, tax and accounting records are separate: they are retained for the period the applicable law requires.
• Code Security uploaded findings, inventories, reports and snippets are retained for the engagement. After it ends they remain available for export for 30 days and are then deleted from active systems, unless an earlier valid deletion instruction applies.
• Code Security's audit log lets administrators evidence access. Its entries are deleted a year after they were written, not earlier with an account or an organisation: an entry about a deleted account names only the anonymised account, and the IP address and approximate location in each entry, and in session, CLI sign-in, token and licence records, are removed after 180 days. FDIE's audit log is kept one year; entries about a deleted account keep no name, email address or IP address.
• Operational and security logs of our infrastructure are kept 180 days. Customer activity logs, backups and protected infrastructure audit records have distinct schedules; the AWS infrastructure table below discloses extended object-version and audit-archive periods, so no single limit covers every category.
• Records of agreement to the Terms of Service and the Privacy Policy, of the age confirmation and of the other choices recorded in Section 4 are kept after the account is deleted, linked only to the anonymised account, for three years, the period within which a claim about the agreement can be brought under the Limitation Act, 1963, and are then deleted.
• When an account is deleted, its registration details (name, email address, organisations, and the dates the account was created and deleted) are kept for 180 days, as the Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021 require of an intermediary, available only to a court or lawful authority, and are then deleted.
• Enquiries, sign-up and sales records in MAGDOX CRM (leads, contacts and web form submissions) are deleted 24 months after our last contact with you, unless you become a customer. Confirmed newsletter consent records are kept while you stay on the list and deleted once you have left it and 24 months have passed since you confirmed. An address that unsubscribed stays on a do-not-email list so that we keep honouring that choice. The CRM's encrypted backups expire after at most 400 days, and the CRM server's own logs are kept 180 days.
• Booking records are kept while we correspond with you and for a reasonable period afterwards to maintain a record of the conversation, then deleted or anonymised.
• A deleted Code Security or FDIE account or organisation is disabled at once, kept for 30 days, during which the deletion can be cancelled, and then erased, with the exceptions in Section 13.4.
• You may request deletion of your data at any time as described in Section 13.

The clocks above, and those in the Terms and the DPA, fit together as follows. A valid earlier deletion instruction takes priority over a general retention window. Restricted backups and records that law requires us to retain are handled separately; these exceptions do not permit continued use for unrelated purposes.

FDIE retention and deletion

Infrastructure lifecycle rules are separate from the application's export, soft-deletion and account-deletion clocks. Some versioned storage copies remain after their current object expires. Valid erasure instructions require identifying affected versions, recovery copies and any retained migration volume; exceptions must have a lawful, limited purpose. The long infrastructure audit schedule must be justified and reconciled with customer instructions before the AWS profile is activated, rather than assumed to be required by law.

For both products, a specific valid DPA instruction is handled within 30 business days, or an earlier applicable legal or contractual deadline. A scheduled deletion start, soft deletion and expiry of all backup copies are different events. Return/deletion confirmation identifies retained backup or legally required copies and their treatment. Deletion instructions must be reapplied after any restore.

11. Data security measures

We implement technical and organisational measures designed to protect personal data, including encryption in transit and at rest, organisation-scoped access controls, audit logging and least-privilege access for our staff. The Security Policy and the Information Security Addendum describe them in detail. We do not claim a formal security certification.

12. Breach notification

In the event of a personal data breach affecting your data, we will notify affected individuals or customers without undue delay, and in any case within 72 hours of becoming aware of the breach, providing the information reasonably available to us at that time. This commitment applies to evaluation and paid customers and website visitors. The 72-hour limit is a contractual outer limit, not permission to delay an earlier notification required by law. For Customer Data we notify the customer as controller, assist its response and coordinate communications to its data subjects. Controller notifications to regulators and individuals have their own legal conditions and deadlines; the customer remains responsible for its decisions. We provide further information in phases as it becomes available.

We report cyber security incidents to CERT-In, India's national incident response team, within six hours of noticing them where the CERT-In Directions of 28 April 2022 require it. Where another law applies to a breach, such as a US state breach law, the GDPR or, once its breach rules are in force, India's DPDP Act, we also notify the authorities and individuals that law requires, within its time limits.

13. Your rights

Depending on your location, you may have rights over the personal data we hold about you, which commonly include the right to access, correct, delete, restrict or object to processing, receive your data in a portable format and withdraw consent. The regional sections below identify the specific regime that applies to you; where more than one could apply, contact us and we will apply the more protective standard.

13.1 India (DPDPA)

See our DPDPA Notice for your rights as a Data Principal under India's Digital Personal Data Protection Act, 2023, including how to escalate a grievance to our Grievance Officer and the Data Protection Board of India.

13.2 United States

If you are a resident of California, Colorado, Connecticut, Delaware, Florida, Indiana, Iowa, Kentucky, Maryland, Minnesota, Montana, Nebraska, New Hampshire, New Jersey, Oregon, Rhode Island, Tennessee, Texas, Utah or Virginia, you may have rights under that state's comprehensive privacy law, as may residents of Louisiana and Oklahoma from 1 January 2027, Alabama from 1 May 2027 and Vermont from 1 January 2028, when those states' new laws take effect. These rights commonly include:

• The right to know whether we are processing your personal data, and to access it
• The right to correct inaccuracies in your personal data
• The right to request deletion of your personal data
• The right to obtain a copy of the personal data you previously provided to us
• The right to non-discrimination for exercising any of these rights
• The right to opt out of targeted advertising, the sale of personal data, or profiling used for decisions with legal or similarly significant effects. MAGDOX does not engage in any of these three practices, so there is nothing to opt out of, but you retain the right to ask

Depending on your state, you may also have the right to know the categories of personal data we process, obtain a list of the categories (or in some states the identities) of third parties we have disclosed personal data to, and limit the use of sensitive personal data. Authentication credentials may fall within a statutory sensitive-information category, and uploaded content can incidentally contain sensitive data. We use such data only for the disclosed service and security purposes and never for advertising. We do not perform profiling that produces legal or similarly significant effects (Section 14).

We retain identifiers, customer-records and professional information for as long as you have an account with us, plus 90 days (Section 10). Internet activity and geolocation data follow the audit-log and technical-log periods in Section 10. Commercial and statutory billing records follow the legal-retention exceptions in Section 10.

We have not sold or shared (as defined under applicable US state law) any personal information in the preceding 12 months. We have disclosed the categories marked above to the service providers described in Section 8, for the business purposes described in Section 5.

Authorised agents. You may designate an authorised agent to submit a request on your behalf under applicable state law. We may require proof that the agent has been validly authorised before acting on the request.

Verification. When you submit a rights request, we verify your identity using the information already associated with your account or, if necessary, by requesting additional information solely for identity verification and fraud prevention.

Appeals. If we decline to act on your request, you may appeal by emailing privacy@magdox.io. We will respond in writing with the outcome and our reasoning. If your appeal is denied, some states allow you to complain to your state Attorney General.

13.3 European Economic Area, UK and Switzerland

Where the GDPR, UK GDPR or Swiss Federal Act on Data Protection applies to our processing, you have the rights provided by that law, and the rights and their exceptions differ between these regimes. You can ask to see the data we hold about you, ask us to correct it or delete it, restrict or object to how we process it (including processing based on our legitimate interests), and ask for a copy in a portable format. Where we rely on consent, you can withdraw it at any time without affecting earlier processing. Section 6 explains the legal bases we rely on. To exercise any of these rights, contact privacy@magdox.io.

If you believe we are unlawfully processing your personal data, you have the right to complain to your Member State's data protection authority, the UK Information Commissioner's Office or, in Switzerland, the Federal Data Protection and Information Commissioner.

13.4 How to exercise any of these rights

Contact privacy@magdox.io or use our Contact page, with your name, the email address associated with your account (if any) and a description of your request. Do not send passwords, authentication codes or identity documents unless we specifically request a necessary, secure verification step. We respond within the applicable legal deadline; for GDPR requests this is normally one month, with any permitted extension and its reason communicated within that month. If the request concerns data a customer controls, we will assist or refer it to that customer as appropriate.

Deleting an account or an organisation. Nobody deletes their own Code Security or FDIE account. Your account is managed by your organisation:

• A Super Admin of your organisation deletes members' accounts (in Code Security from Members, in FDIE from Settings, Team), so ask them. A person who also belongs to another organisation keeps their account; a Super Admin or an admin can instead remove them from the organisation, which also keeps the account.
• A Super Admin who wants their own account deleted makes another member Super Admin, who can then delete it, or writes to privacy@magdox.io.
• A Super Admin can delete the whole organisation, in Code Security under Settings, Danger Zone and in FDIE under Settings, Data & Privacy, after typing DELETE and confirming with their password or authenticator code. The accounts that belong only to that organisation are deleted with it.
• MAGDOX staff can also delete an account or an organisation, for example after a request to privacy@magdox.io: on the same 30-day schedule or, when there is a verified reason, at once. When the person is the only member of an organisation, the organisation is deleted instead.

When a deletion is scheduled:

• The account is disabled at once, or everyone in the organisation is signed out at once, and every session, API key and token concerned stops working.
• For an organisation, renewal is paused, so no renewal charge is taken while the deletion is pending, and processing pauses: no new analyses or scans run and scheduled jobs stop. If the period already paid for ends first, the plan simply ends; if it runs past the deletion date, the subscription ends on that date.
• We email the member whose account is deleted, or every member of the organisation being deleted.
• The data is kept for 30 days and then erased. Until then the deletion can be cancelled: a Super Admin reactivates the organisation by signing in, and can restore a member's account that the organisation deleted. A deletion MAGDOX staff scheduled is cancelled only by MAGDOX. A reactivated organisation whose plan ended in the meantime must choose a plan again.
• What a deleted member uploaded or decided stays with the organisation: in FDIE their firmware is credited to another member, and in Code Security their findings, comments and decisions show as Deleted user.

After erasure we keep only:

• Security logs of our infrastructure and sign-in service, for up to 180 days under our Security Policy, and the longer infrastructure records listed in Section 10.
• The organisation's audit log, which no longer identifies the person: FDIE removes their name, email address and IP address and deletes each entry a year after it was written; Code Security entries name only the anonymised account, lose their IP address and location after 180 days, and are deleted a year after they were written.
• Billing and tax records the law requires: Dodo Payments keeps them as merchant of record for online purchases, and we keep our accounting records for agreements we invoice directly.
• Records of agreements and of the other choices in Section 4, as evidence, linked only to the anonymised account, for three years (Section 10).
• The account's registration details, for 180 days, as the IT Rules 2021 require, available only to a court or lawful authority (Section 10).
• Records that stop unwanted email or repeated offers: the do-not-email list; the list of addresses that bounced or complained (a hash of each address); the keyed hash MAGDOX CRM keeps so that deleted billing records are not copied back; the hashed addresses that stop a money-back refund being claimed twice; and, in Code Security, a hash of the address that started a free trial, so that each person has one trial.
• Backups and earlier versions of stored files until they expire under the schedule in Section 10; a deletion is applied again if a backup is ever restored.
• Error reports already sent to Sentry and, if you allowed analytics, events already sent to PostHog, until those services delete them. They carry an internal identifier that no longer leads to you; FDIE gives the erased account a new one.

Code Security risk management is an exception. Risk acceptance decisions and the history of findings and risk are kept by design when an organisation is erased, linked only to anonymised accounts. An organisation that has risk teams, asset context or verification evidence keeps its name, its settings and those records. On the deletion date everything else goes as for any other organisation: its findings data is deleted, apart from repositories whose findings carry verification evidence; its members' accounts that belong to no other organisation are anonymised; and its memberships, sessions, tokens, integrations, webhooks, report schedules and sign-in domains are deleted.

14. Automated analysis and decision support

MAGDOX Code Security findings, severities and inventories are produced by deterministic, rule-based static analysis and vulnerability matching, and are intended as decision-support information for your security and engineering teams. Optional AI review runs only when a customer enables it, with the customer's own model provider, and records an advisory verdict next to the engine's finding, marked as AI-generated; it never removes a finding, and only when a user opts into --ai-gate can a high-confidence false-positive verdict keep that finding from failing a CI gate. None of this is used by MAGDOX to make a solely automated decision producing legal or similarly significant effects about an individual, and we do not build profiles of individuals from it. FDIE uses rules, matching and templates for static findings and bounded runtime observations, with analyst review; it does not generate findings with language models. Reviewer decisions in either dashboard are made by people in the customer organisation. See Terms of Service Section 15 for the scope and limitations of the analysis.

15. Children's privacy

The Service is not directed at, and is not intended for use by, individuals under the age of 18. We do not knowingly collect personal data from anyone under 18. Everyone who creates an account confirms that they are at least 18, and we record that confirmation; we do not ask for a date of birth or identity documents. If we learn that we have, we will take reasonable steps to delete it and deactivate the associated account. Contact privacy@magdox.io if you believe we may have collected data from a minor.

16. Changes to this policy

We may update this Privacy Policy from time to time. Material changes will be communicated on this website or by email to the designated contact of affected customers. The last updated date at the top of this page reflects the most recent revision. Prior versions are archived and available on request.

17. Contact

Questions about this Privacy Policy can be sent to privacy@magdox.io or through our Contact page, or by post to MAGDOX Private Limited, St No. 8, Arabinda Nagar, Barbani, Bardhaman, Hindustan Cables, West Bengal 713335, India.