Privacy Policy

AUREVELLAN TECHNOLOGIES PRIVATE LIMITED (“Get Lightning”, “we”) operates the website at www.getlightning.cloud and the Lightning Pharos application at www.lightningops.in. This policy covers both.

Get Lightning is a brand of AUREVELLAN TECHNOLOGIES PRIVATE LIMITED.

We were incorporated in India on 25 September 2026. Our registered office, CIN and GSTIN are listed in the company details below.

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 request a walkthrough or quote, we collect the details you choose to provide:

• Name, work email, company, phone number, and team size
• Product interest and any message you write
• The request time, source information supplied with the request, and your recorded contact permission

Hosting and delivery logs can contain your IP address and request metadata; enquiry records do not store your IP address. Lightning Sheets is no longer offered: new downloads and related notifications are disabled. Historical download records remain subject to our existing retention policy.

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 improve how we follow up : for example, matching a stated product interest to the right person here

Our enquiry forms ask for your permission before you submit your details. We use those details to respond to your request and discuss related solutions through the contact details you provide. Product-update requests have a separate permission for those updates. We record your choice, the permission text version and the time of submission. You can withdraw permission or request deletion by contacting us.

Where a form submission actually goes

Walkthrough and project enquiries are saved in Lightning Pharos. The website service also stores a durable notification request; product-update requests stay in that service. Notifications are queued independently, and uncertain delivery is held for review rather than automatically resent. A queued request or provider acceptance does not establish inbox receipt. You do not need to submit a saved enquiry again. Website notifications use the existing private Hostinger Mail relay, sent from info@lightningops.in to our internal enquiry team.

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.

Standard plan and Quote ID checkout

New purchases are currently assisted. We confirm the legal seller, taxes, final amount and purchase document in writing before payment.

You can choose an available standard Pharos plan or enter a private Quote ID. A Quote ID also requires its billing email before we show the agreed offer. Checkout displays the price, term, seats and applicable modules before payment. When you prepare the order, 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 Get 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.

Shopify connection data stays with the merchant’s Pharos workspace on the existing Hostinger application server. Its physical datacenter location is unverified. Shopify sends the data 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.

Workspace data

Pharos workspace records remain on the existing Hostinger application server; its physical datacenter location is unverified. This website migration does not move workspace records. Data in transit is encrypted with TLS.

Supabase Auth and optional Google sign-in are separate from workspace hosting. They process sign-in identities, not business workspace records. Password sign-in for a linked account still uses Supabase. Their processing locations are not established by this website migration.

This website and its operational records

Public website pages and assets are stored in Amazon S3 in Mumbai and delivered through AWS CloudFront’s global network. Website notification and optional measurement records are stored and processed on AWS in Mumbai. Operational enquiries are also saved in the separate Hostinger Pharos application, whose datacenter location is unverified. Earlier AWS records have not been recovered or imported.

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 for the separate Pharos application. Its physical datacenter location is unverified. This website migration does not move workspace records. It also delivers 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

• Hostinger Mail : sends enquiry notifications from info@lightningops.in to our authorised internal team. Provider acceptance is separate from inbox receipt.
• Amazon Web Services : S3 and Lightsail host public assets, website notification and optional measurement records, and private relay processing in Mumbai. CloudFront delivers public assets worldwide. Earlier AWS enquiry, download and measurement records have not been recovered or imported.
• Razorpay : payment gateway for standard plans and accepted private Quote IDs. 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.
• Optional website measurement stores aggregate events without contact details or form contents. Enquiry notification records and retained historical download records are kept separately from those aggregates.
• Access by our own people is limited to those who need it, and everyone here is under a confidentiality obligation that outlasts their employment.
• Pharos workspace backups are taken daily. Backup and recovery capability for the new website service store has not yet been verified.

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. The controls described here are not a certification or a claim that an independent security audit has been completed. We will describe our controls in response to a customer’s security review.

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 remains uncertain, what we are doing, and what we recommend. We help them meet applicable notification duties as Data Fiduciary. The DPDP Board and individual-notification procedures apply when the relevant provisions are in force. We will not wait for certainty before telling the customer 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 in the website footer. It counts page categories and named actions and measures loading, responsiveness and layout stability. Its event records exclude names, emails, form content, query strings, advertising identifiers and session recordings. No Google Analytics, advertising pixels or session recorder is installed. An eligible checkout loads Razorpay’s payment script before you press Pay, so Razorpay receives the technical request needed to load it. The hosted payment window opens only when you choose to pay. Razorpay may use storage for fraud prevention and payment processing.

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 checkout hand-off, in session storage: the selected plan or 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. A Quote ID and its billing email are sent to Pharos when the quote is checked. Plan selections and seat counts are used to request a price preview; buyer details are sent 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 new VPS measurement store contains only daily aggregate counts by page category, broad device category and event or performance bucket. Collection requires optional measurement consent and honors browser Do Not Track and Global Privacy Control. The reporting window is 90 days; older counts are removed when a new measurement is written. It has no visitor profile or cross-visit identifier. Previous AWS measurement records remain unrecovered. Ordinary hosting logs can contain your IP address and request metadata.

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 DPDP Act provides for the rights below through staged commencement. We already accept these requests as privacy commitments for personal data we hold as Data Fiduciary and support customers with workspace requests. Statutory rights and Board procedures apply when the relevant provisions are in force.

• 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, one email is enough to withdraw it. We will stop using the data for that purpose; withdrawal does not undo earlier lawful use. When registered Consent Manager routes become available under the Act, we will honour a valid 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 Pharos 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. We do not market it to children or knowingly collect personal data from anyone under 18 through this website. We do not use advertising pixels, session recordings or individual behavioural profiles. Optional aggregate website measurement is described in section 10.

Customer workspaces may contain records about apprentices or trainees under 18. The customer is the Data Fiduciary and must establish a lawful basis and meet applicable safeguards for those records. Section 9 of the DPDP Act provides for verifiable parental consent and other safeguards when it comes into force, subject to applicable exceptions. We process these records on the customer’s instructions and help them meet their obligations.

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, the DPDP Act provides for a complaint to the Data Protection Board of India after first raising your grievance with us. That statutory route applies when the relevant provisions and procedure are in force. Our response commitments above apply now.

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.