Privacy Policy

Lightning Technologies Private Limited (“Lightning”, “we”) operates the website at www.getlightning.cloud and the Lightning Pharos application at www.lightningops.in. This policy covers both.

Our company name is reserved with the Ministry of Corporate Affairs and incorporation is in progress; we are not yet on the MCA register, so there is no CIN or GSTIN to publish here today. The full position, including the reservation number you can look up, is in clause 1 of our Terms. We mention it in a privacy policy because you are entitled to know who is holding your information before you decide to give us any.

Our Grievance Officer is named in section 13, and answers in person.

The distinction matters, because it decides who is answerable for what. The DPDP Act calls the decider a Data Fiduciary, the party acting on their instructions a Data Processor, and the person the data is about a Data Principal. We are one of the first two depending on whose data it is.

If you are an employee of a Lightning Pharos customer and want to know why your data is in there, ask your employer first: they control it, not us. If you ask us, we will point you to them rather than act on their data without instruction : and we will tell them you asked.

What we collect

When you book a walkthrough, request a quote or ask for a download, we collect what you type:

• Name, work email, company, phone number, and team size
• Product interest and any message you write
• Which Lightning Sheets release you requested and when the download started
• The web address the request came from, and the time it arrived

Your IP address appears in ordinary web-server access logs, as it does on any website. It is not stored on the enquiry record itself, and we do not use it to build a profile of you.

There are no accounts and no passwords on this website. We do not sell your personal information, and we have never sold or rented a marketing list.

How we use it, and on what basis

• To reply to walkthrough and product enquiries
• To notify you about products you asked to hear about
• To understand adoption of our Windows and Android releases
• To improve how we follow up : for example, matching a stated product interest to the right person here

The basis is section 7(a) of the DPDP Act: you gave us the information voluntarily, for a purpose you can see on the form, and you have not told us not to use it for that. We do not put a consent checkbox in front of a walkthrough request, because a ceremony nobody performs is not consent. If you would rather we did not hold it at all, say so and we will delete it.

Where a form submission actually goes

A form on this site is recorded in two systems we operate. It is added to the Lightning Pharos enquiry queue so our team can follow it through the CRM, and it is stored in a durable notification queue on the marketing server. A notification email is sent to us through Amazon Web Services (Simple Email Service), configured in its Mumbai region. It is not sent to a third-party form service.

Please do not send passwords, payment card numbers, or sensitive personal data in a form message. There is no reason to, and we would rather not hold them.

Private Quote ID checkout

If we give you a private Quote ID, this website asks for the billing email attached to it before showing the agreed price, term, seats and modules. When you continue, your name, email, optional phone number, company and billing address go to the Lightning Pharos API so we can create the purchase record and payment receipt.

Payment is then collected in a Razorpay-hosted checkout. Razorpay receives the order amount and identifier, your payment instrument details, and the name, email and phone used to prefill its checkout. Complete card, bank and UPI credentials go to Razorpay and are not sent to or stored by Lightning. After Razorpay reports a captured payment, Pharos emails the receipt and a one-time workspace-onboarding link to the billing email.

Signing in

You can sign in with an email address and a password, or optionally with Google.

If you choose Google, Google authenticates you and returns your email address, basic profile information, and a stable account identifier. We store the identifier so we can recognise you on your next sign-in, and the email address so we know which account you are. That is all we ask Google for, and all we receive: we request no access to Gmail, Drive, Contacts, Calendar or any other Google service, and your Google password is never sent to us.

Information received from Google is used only to sign you in and operate your account. We do not use it for advertising, we do not sell or share it, and we do not use it to train models. Our use of it complies with the Google API Services User Data Policy, including its Limited Use requirements. You can disconnect Lightning from your Google account at any time in your Google account settings, and sign in with a password instead.

Passwords we hold are stored only as salted one-way hashes : we cannot read them, and a password reset issues a single-use code that expires. If you enable two-factor authentication, the secret behind it is encrypted before storage.

Workspace data

A workspace holds whatever the customer puts into it. In practice that includes employee records, attendance and leave, payroll figures, customers and suppliers, orders, stock, financial entries, and uploaded documents.

Some of it is sensitive personal data under the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011. Which categories appear depends on what the customer switches on, and in practice they are: financial information such as bank account details held for salary credit; health and medical information where medical leave or fitness records are kept; biometric information where a customer uses biometric attendance; and passwords, which we hold only as hashes.

We process all of it to provide the service : running the features the customer has switched on, keeping it available, backing it up, and supporting them when they ask. We do not sell it. We do not use it for advertising. We do not use it to train models. We access it ourselves only when it is necessary to operate the service or when a customer asks us to help with something specific, and those actions are logged.

A Shopify store connected to Pharos

A merchant chooses whether to install Lightning Pharos and approves the access on Shopify. The app currently requests these Shopify Admin API scopes: read_products, write_products, read_locations, read_inventory, write_inventory, read_orders, and write_merchant_managed_fulfillment_orders. Those permissions let the connector use:

• the store’s permanent .myshopify.com domain, which is the identity used to keep each connection separate;
• current products and variants, including Shopify identifiers, titles, product status and update time, and variant SKU, barcode, and price, for an inbound Pharos catalogue import;
• current location identifiers, names, and active status; and
• inventory-item identifiers, SKU and tracked status, plus the available and on-hand quantities for each item and location; and
• order identifier, order name, payment status, fulfilment status and update time. The connector does not import the shopper’s Shopify customer profile, address or payment instrument details.

When an authorised Pharos user changes mapped catalogue or stock data, Pharos can write the corresponding product, variant or available inventory quantity to the connected stores. A recorded delivery handover can also create a merchant-managed fulfilment with its tracking code. These writes are scoped to mapped records, are audit logged, and use retry-safe operation identifiers. The connection does not request Shopify customer access, and it adds no script, pixel, cookie, or tracker to the storefront.

An authorised user can start catalogue, inventory and order refreshes from the Shopify screen. Configured background jobs can repeat those refreshes and deliver queued write-backs. Pharos records observation, attempt and confirmation times so a user can see whether a value is current, pending, confirmed or needs attention.

Shopify issues an OAuth access token and refresh token after the merchant approves the install. We encrypt both before database storage, decrypt them only on the server when Pharos calls Shopify or rotates an expiring token, and never send them to the Pharos browser. During a public install, an encrypted approval can wait for up to 15 minutes while the signed-in administrator assigns it to the intended workspace; it is single-use, cannot be used after expiry, and is deleted when claimed or next encountered after expiry.

We keep the operational facts needed to make the connection supportable: approved scopes, connection and health state, sync times and counts, provider identifiers and pagination cursors, and error categories. For signed lifecycle and privacy webhooks we retain the delivery identifier, topic, time, outcome, and a one-way hash of the payload instead of the raw privacy payload. Application logs record events and identifiers, not product records or OAuth tokens.

This Shopify data is stored with the merchant’s Pharos workspace on infrastructure operated by Hostinger in Mumbai, India. Hostinger is the hosting sub-processor named in section 6. Shopify sends the data from the merchant’s own Shopify service at the merchant’s direction.

If the app is uninstalled, Pharos deletes the stored Shopify tokens and disables further access. When Shopify sends the required shop-redaction event, a background erasure removes the store’s active connection, pending approvals, inventory snapshots, mappings, and store-attributable operational records. Catalogue records created only from that store are redacted and archived; a row also linked to another source is kept without the deleted store’s link so erasing one store does not destroy another store’s data. A non-reversible shop fingerprint and a scrubbed completion receipt remain so a late callback or replay cannot recreate erased data; neither retains the store domain or webhook payload. Copies already inside recovery backups are not rewritten in place; they remain protected from ordinary use and age out on the normal backup cycle.

A merchant can ask about access, correction, export, or deletion by emailing ansh@getlightning.cloud with the permanent Shopify store domain and the Pharos workspace name : never a password or token. A shopper should contact the merchant that controls the store; the connector does not import Shopify customer profiles, and we support the merchant when Shopify sends a required privacy request. Installation help is on the public Shopify support page.

Automated features

Where the product analyses your own records to produce a summary or a suggestion, that happens against your workspace and no third-party AI provider appears in the list in section 6. If we ever introduce a feature that sends workspace content to an external model, we will name that provider in section 6 before it is switched on, and it will be something a customer turns on rather than something that arrives on.

Your workspace data: India

Business workspace records, separate from the sign-in processing described below, are stored on dedicated infrastructure operated by Hostinger in Mumbai, India. It is not replicated outside India for ordinary operation. Data in transit is encrypted with TLS.

Sign-in is a separate processing path. Supabase Auth holds linked sign-in identities and can verify passwords for those accounts over TLS. Google sign-in also uses Google's infrastructure. The India location of business workspace records is not a promise that all authentication processing stays in India. Choosing a password instead of Google does not bypass Supabase for a linked account. Neither authentication provider receives your business workspace records through this sign-in flow.

This website: India

The marketing site you are reading, its aggregate measurement store, and its delivery copy of an enquiry run on an Amazon Web Services virtual machine in Mumbai, India. Data in transit is encrypted with TLS and the server volume is encrypted at rest. The operational enquiry is also recorded in Lightning Pharos in Mumbai, India.

If any of the above changes, we will say so on this page before it changes, and name the country.

We keep the list short on purpose, and each list below is the whole list for that side of the business.

For the Pharos application

• Hostinger : hosting (servers, database, storage) in Mumbai, India, and delivery of transactional email such as invitations and password-reset codes.
• Supabase : authentication only. It holds sign-in identities, not your workspace records.
• Google : only if you choose to sign in with Google, and only for that.
• An external uptime monitor, which requests public health endpoints and sees no personal data.

For this marketing website

• Amazon Web Services : the server that serves these pages and holds enquiry and aggregate measurement records in Mumbai, India; and Simple Email Service in Mumbai, which delivers the notification email when you submit a form.
• Razorpay : payment gateway for an accepted private Quote ID. It processes the payment instrument and returns payment status and provider identifiers to Pharos.

For customers, this is contractual and not merely a page we maintain: we give at least 30 days’ notice before a new sub-processor begins processing workspace data, and a customer who reasonably objects on data-protection grounds may terminate the affected part of the service without penalty. That commitment lives in clause 13 of the Terms.

What we actually do, stated plainly rather than as a badge:

• Every workspace’s data is scoped to that workspace, and that isolation is verified by an automated test suite that blocks a release if it fails.
• Access to workspace records is checked against the authenticated identity and its permissions. Unauthorised requests are denied.
• Administrative actions are recorded in an audit trail, and two-factor authentication is available.
• Records are logged by identifier rather than content, so message bodies, phone numbers and email addresses do not accumulate in logs.
• Access by our own people is limited to those who need it, and everyone here is under a confidentiality obligation that outlasts their employment.
• Backups are taken daily, and restoring from them is rehearsed rather than assumed.

What we do not claim

Data in transit is encrypted with TLS. We do not encrypt workspace records a second time at the application layer, and we are not going to describe our storage as encrypted at rest until we can point at the provider’s written confirmation of it rather than an assumption. What protects those records today is the list above.

We do not hold an ISO/IEC 27001 certification, and we will not claim one we have not earned. The SPDI Rules recognise a documented security programme with controls proportionate to the information being protected as an alternative way of demonstrating reasonable security; the controls above are ours, and we will describe them in as much detail as a customer’s security review asks for.

No system is perfectly secure. If you believe you have found a vulnerability, report it to ansh@getlightning.cloud : we will acknowledge it, we will not threaten you for reporting it in good faith, and we ask only that you do not test against other customers’ data.

If we become aware of a security incident affecting personal data in a customer’s workspace, we tell that customer without undue delay : what we know, what we do not yet know, what we are doing, and what we recommend they do. Under the DPDP Act the duty to notify the Data Protection Board of India and the individuals affected is theirs as Data Fiduciary, and they cannot meet it if we are slow. We will not wait for certainty before telling them something has happened.

For personal data we hold in our own right : enquiries from this website, and our own account records : we are the Data Fiduciary, and we will notify the Board and the people affected as the Act requires.

Enquiries from this website

We review enquiry records at least once a year and delete anything where there has been no contact for 24 months. Being precise about the mechanism as well as the period: that review is a manual step we perform, not an automatic expiry the software enforces, and we would rather tell you that than describe a job we have not written. You can ask us to delete your enquiry at any time and we will, without asking why.

Workspace data

While a workspace is active, its data stays until the customer deletes it. After a subscription ends we keep it for 90 days so the customer can export it, then remove it from active systems; copies inside backups age out on the normal backup cycle. A customer can ask for earlier deletion, or a different arrangement in writing, and we will confirm a deletion when it is done. The same 90 days is written into clause 16 of the Terms, so it is a contractual commitment and not just a policy we could revise.

This site sets no advertising cookies. Optional, first-party measurement is off until you allow it through Privacy choices at the bottom of any page. It counts page categories and named actions, such as opening a trial or successfully sending a request, and measures loading, responsiveness and layout stability. It does not collect names, emails, form content, query strings, advertising identifiers or session recordings. No Google Analytics, advertising pixels or session recorder is installed. The private checkout page loads Razorpay’s payment script only to open the hosted payment flow after you choose to pay an accepted quote; Razorpay may use storage required for fraud prevention and completing that payment. You can verify the page-level boundary in your browser’s network tab.

The following are stored on your own device:

• Your optional measurement choice, in local storage. You can turn it off at any time through Privacy choices. Do Not Track and Global Privacy Control override an allowed choice.
• The emulator's example records and the name and business details you enter for the sample, in session storage. They remain on this device until you reset the sample or close the tab. Chosen workflow context reaches us only when you submit a request.
• Your chosen language, in local storage, so the site opens in it next time.
• Your answers to the industry picker and the ten-second test, in session storage, which pre-fill the message if you go on to request a walkthrough. They reach us only if you submit that form, and they disappear when you close the tab.
• Your private-checkout hand-off, in session storage: the Quote ID, billing email, buyer details you enter, seat count when relevant, and a random attempt identifier used to resume the same purchase safely after a refresh. The Quote ID and email are sent to Pharos when the quote is checked; the remaining checkout details are sent only when you prepare the order. This browser copy disappears when the tab is closed, the completed checkout clears it, or you intentionally start over.

The measurement store contains daily aggregate counts by page category, broad device category and event or performance bucket. It is hosted with this website in Mumbai, India and kept for up to 90 days. It has no visitor profile or cross-visit identifier. Normal hosting access logs can still contain your IP address when requests reach the server.

Clear your site data and the local preferences are gone. The Pharos application sets a session cookie to keep you signed in; that one is necessary for it to work at all.

The Digital Personal Data Protection Act, 2023 gives a Data Principal in India four rights. We honour them for the personal data we hold as Data Fiduciary, and we support our customers in honouring them for workspace data.

• Access to information about processing (section 11 of the Act) : a summary of what we hold about you, what we do with it, and who else we have shared it with.
• Correction, completion, updating and erasure (section 12 of the Act).
• Grievance redressal (section 13 of the Act) : Grievance Officer and complaints below tells you how, and the Act asks you to raise it with us before going to the Board.
• Nomination (section 14 of the Act) : you may nominate someone to exercise these rights on your behalf if you die or become incapacitated. Email us and we will record it.

Where we rely on your consent, you can withdraw it as easily as you gave it : one email is enough : and we will stop using the data for that purpose, though withdrawal does not undo what was lawful before it. If you route consent through a Consent Manager registered with the Data Protection Board, we will honour a withdrawal made that way.

Some of these rights have equivalents elsewhere in the world. If you are outside India and think a local law gives you a right we have not listed, write to us and we will deal with the substance of what you are asking rather than argue about jurisdiction.

• For information you gave this website, or for your own Lightning account, email ansh@getlightning.cloud and we will handle it.
• For data inside an employer’s or supplier’s workspace, contact them : they decide, and we will support them in responding.

This is a product for businesses, and we do not market it to children or knowingly collect personal data from anyone under 18 through this website. We do not track, behaviourally monitor, or target advertising at children : we do not do any of those things to anyone.

A workforce product does meet people under 18: apprentices and trainees appear in customer workspaces. Where that happens, the customer is the Data Fiduciary and it is their obligation under section 9 of the DPDP Act to obtain verifiable parental or guardian consent and to handle that record properly. We process those records on their instruction like any other, and we will help a customer meet the obligation if they ask us how.

Under Rule 5(9) of the SPDI Rules, 2011 and the Digital Personal Data Protection Act, 2023, we publish a named officer who is answerable for complaints about how we handle personal data. Not a team, not a role account : a person.

We acknowledge a grievance within 2 business days, aim to resolve it within 15 days, and will not exceed one month : the outer limit the SPDI Rules set. If we need longer than 15 days we will tell you why before the 15 days are up, rather than after.

If you are not satisfied with our answer, you may complain to the Data Protection Board of India. The Act asks you to raise it with us first, which is the only reason we ask you to as well.

We may update this policy. The date at the top tells you when it last changed, and we will give customers at least 30 days’ notice of a change that materially affects how we handle their data : the same notice period clause 13 of the Terms commits us to for a new sub-processor.

We do not backdate. A change takes effect when it is published, and a commitment made in the version you signed under governs your current term.

Questions about this policy, or a request about your information: ansh@getlightning.cloud. See also our Terms of Service, or book a walkthrough.