Who this notice is from
This notice explains what Cloudheal Solutions (India) Private Limited does with personal data in Cloudheal, the exposure management platform at easm.cloudheal.com.
Cloudheal Solutions (India) Private Limited is a company incorporated in India, with its registered office at Unit 101/B-1, First Floor, Raheja Plaza-1, LBS Marg, Ghatkopar West, Mumbai - 400086. In this notice it is called "we", "us" and "our".
We act as the Data Fiduciary in respect of personal data for which we determine the purpose and means of processing, including account administration, authentication, platform security, billing and audit records.
Where we process personal data contained in findings, assets, scans and exposure information solely on behalf of a customer organisation and in accordance with its instructions, the customer organisation acts as the Data Fiduciary and we act as its Data Processor.
Who this notice covers
It covers three groups, and the third is the one such a notice usually forgets.
- People given access to Cloudheal by a customer organisation: its administrators, analysts, operators and viewers.
- People named in the registration records a domain registry publishes about a customer's own domains.
- People outside any customer organisation whose details appear in what a scan finds. This includes the registrant of a lookalike domain, and the user of a device reported by infostealer malware. They have no relationship with us and did not choose for their details to be reported.
For the third group we hold only what a public register or a breach source already published, we do not use it to contact them, and we do not enrich it. A person in that group may ask us what we hold about them and ask us to erase it, using the contact details at the end of this notice, and we will do so unless keeping it is required by law.
Customer organisations must use personal data relating to third parties only for legitimate cybersecurity, incident response and remediation purposes and in accordance with applicable law. Such information must not be used for marketing, profiling, surveillance, credential exploitation or to obtain unauthorised access to any account, system or infrastructure.
What the platform holds
Account and sign-in records
For every person given access we hold a name, an email address, whether that address has been verified, and the date the account was created. A password is set by the person through a one-time link and is stored only as a hash. We do not hold the password itself.
For every active session we hold the originating IP address, the browser and operating system reported by that browser, and the time the session was last used. Sessions expire after eight hours of inactivity by default.
An administrator of an organisation can see the sessions of other members of that same organisation, including their IP addresses and the browsers they signed in from. This lets an administrator find and end a session they do not recognise.
Domain and asset information
When an organisation adds a domain, the platform records what is publicly discoverable about it. This includes registration records published by the domain registry, which carry the name, organisation, email address, telephone number and postal address of up to three contacts. That information is published by the registry rather than uncovered by the scan, and it is held with the rest of the inventory.
Two modules report on domains the organisation does not own: lookalike domains, and domains associated with the organisation's own. Where a registry publishes a registrant name or email address for one of those, the platform records it.
Dark web exposure
The dark web module reports exposures connected to an organisation's domains. What it holds is narrower than the phrase suggests, and the difference matters:
- No leaked password is stored. The platform does not retrieve credential values at all, and has no place to put one.
- No screenshots are stored.
- A breach appearance is held as information about the breach: its name, its date, and the categories of data it exposed. That is a fact about the breach rather than about a person.
- Where a username, a web address or a machine name is held, it is encrypted with a key belonging to that one organisation, and the screen shows a fixed-width masked preview until somebody with the right role asks to see it and gives a written reason.
- Records reported by infostealer malware include a system username and a machine name, which may identify a device and the person using it.
If a record cannot be masked safely it is discarded rather than stored. If an organisation has no usable encryption key, ingestion fails rather than storing anything in the clear.
Records of what people did
The platform keeps an audit record of actions taken in it: domains added and removed, scans started and stopped, credits granted and adjusted, roles changed, people invited and disabled, settings changed, reports exported, and every request to reveal a dark web value. Each entry records who acted, what they acted on and when.
Requests to reveal a dark web value are recorded separately, with the reason given, in a record linked by digest to the one before it so that a single entry cannot be altered without the rest showing it.
Reading a finding is not recorded. The audit record covers changes and reveals rather than every view of a screen.
Why the platform holds it
Personal data is held for these purposes and no others:
- To give a named person access, to establish that they are who they say they are, and to record what they did with that access. We rely on the performance of our contract with the customer organisation.
- To discover what a customer organisation exposes to the internet and report it to that organisation. Performance of the same contract.
- To tell a customer organisation that credentials or devices connected to it appear in a breach or in infostealer output, so that it can secure the accounts affected and tell the people involved. We rely on the legitimate interest of the organisation and of the people whose accounts are at risk in having that exposure made known.
- To account for credits consumed and to bill for them. Performance of the contract, and our legal obligation to keep accounts.
- To keep the platform secure and available, including rate limiting and fault diagnosis. Our legitimate interest in operating a secure service.
- To meet obligations the law places on us.
- We process personal data for the purposes described above in accordance with applicable data protection law, including on the basis of consent or other grounds for processing permitted under applicable law, as relevant to the particular processing activity.
What the platform does not do
The platform carries no analytics, no advertising technology, no tracking pixels and no profiling. Nothing about how a person uses the screens is sent anywhere. Personal data is not used to train machine learning models, and it is not sold, rented or shared for marketing.
Cloudheal currently uses only cookies that are necessary for authentication, operation and user preferences. If non-essential cookies or similar technologies are introduced, we will provide any notice or choice as required by applicable law.
Where the data is held
The platform and its database run in Mumbai, in the asia-south1 region of Google Cloud. Backups are held in Delhi, in asia-south2, for thirty five days. Both are in India, and the configuration refuses a multi-region setting that would move backups out of the country.
Two things leave India, and both are stated here rather than left to be discovered:
- Fault reports raised when the software fails are sent to an error monitoring service hosted in the United States. Those reports pass through a redaction layer that removes credentials, keys, dark web values and stack traces before anything leaves the server.
- Operational logs written by our cloud provider's default logging service are not pinned to a region. They record how the software behaved rather than what it found.
- Where personal data is transferred to, accessed from or otherwise processed outside India, we will do so in accordance with applicable Indian law and subject to any restrictions or requirements notified by the Central Government from time to time.
Who else processes the data
We use a limited number of service providers and processors to operate and support the platform. A current list, naming each one and what it does, is available to customers on request under confidentiality. By function they are:
- An external scanning provider, which performs the scans. It receives the domain names to be scanned and nothing else. It does not receive names, email addresses or any other personal data from this platform.
- Google Cloud, which hosts the platform, its database and its backups, in India.
- Microsoft, which carries the platform's outgoing email through our own Microsoft 365 tenancy.
- An error monitoring provider in the United States, which receives redacted fault reports.
- We may also disclose personal data where required by applicable law, court order or a competent governmental or regulatory authority, or where reasonably necessary to investigate, prevent or respond to fraud, misuse or cybersecurity incidents, subject to applicable law.
We may be required to transfer, store, or otherwise process your personal data outside India where necessary for the purposes described in this Privacy Notice, including where we engage service providers, affiliates, or other third parties located outside India. Any such transfer or processing will be undertaken in accordance with the applicable laws, as applicable. We will comply with any restrictions, requirements, or safeguards prescribed by the Central Government in relation to the transfer of personal data outside India.
The platform sends three kinds of email and no others: an invitation, a password reset, and an address verification. Each carries the recipient's address, the product name and a one-time link. None carries a name, a role, an organisation or any finding. A copy of each message is retained in the sending mailbox, which we administer.
How long data is kept
Dark web records are disposed of three hundred and sixty five days after this platform received them, which an administrator may set between thirty and three thousand six hundred and fifty days. The clock runs from the date the platform took custody rather than the date of the breach. Disposal destroys the encrypted values and leaves a record that the disposal happened.
The record of who revealed a dark web value is deliberately not disposed of with it, so that the account of who saw what survives the disposal of the thing they saw.
Other data is kept as follows:
- Findings, scans and asset inventories, including domain registration contacts: [period], from the date of the scan that produced them.
- Account and membership records: for as long as the person has access, and [period] afterwards.
- Sign-in session records: until the session expires.
- The audit record and the credit ledger: [period], and in any event for as long as we are required to keep accounting records.
Notwithstanding the retention periods stated above, we may retain personal data or records for a longer period where retention is required or permitted by applicable law, regulatory direction, legal proceedings, investigation or applicable cybersecurity requirements.
Removing data, and erasure
Removing a domain, a scan or an organisation hides it. The customer stops seeing it and everything beneath it, and the audit record, the credit ledger and the record of dark web reveals are untouched and remain readable by the people who audit them. Nothing is erased by that act.
This is deliberate. Records of who accessed leaked credentials are retained rather than deleted, so that the account of who saw what survives the disposal of the thing they saw.
Where a person asks us to erase personal data and we are not required to keep it, we will do so within thirty days. Two limits apply and we state them rather than discovering them with you:
- Backups are held for thirty five days. Data erased from the live platform may persist in a backup until that backup expires, and we do not restore a backup to remove it. Erasure is complete once the backups covering the period have expired.
- Entries in the audit record and the record of dark web reveals are not erased, because they are the evidence that an access happened. They name the person who acted, not the subject of a finding.
One act erases immediately. We can destroy an organisation's dark web encryption key, which makes every dark web value held for that organisation permanently unreadable. It does not touch findings, assets, registration contacts, the audit record or the ledger, and it cannot reach a backup taken before it ran.
How the data is protected
- Each customer organisation's data is separated at the database itself, by row-level security, and again by the application. A connection that does not declare which organisation it is acting for reads nothing at all, so the separation fails closed.
- Platform staff hold no permission to read finding content. Reading it requires a separate break-glass role, a written reason recorded before the read, and it expires after one hour.
- Dark web values are encrypted with AES-256-GCM using a key held for that one organisation. The master key never enters the application and cannot be exported from the key store.
- Revealing a dark web value is one field at a time, with no bulk path, and the audit entry is written before anything is decrypted.
- Sign-in attempts and sensitive actions are rate limited.
- Data is encrypted in transit, and at rest by our cloud provider's platform encryption.
- The audit record is tamper-evident. No role the platform runs as can change or delete an entry and the database refuses it, and the separate record of dark web reveals is additionally chained by digest so that altering one entry shows in the rest.
If something goes wrong
Where a personal data breach occurs, we will notify the Data Protection Board of India and each affected person without undue delay, and in any event within seventy two hours of becoming aware of it. The notice will describe what happened, what data was affected, what we are doing about it, and what the person can do.
Where the people affected are not reachable through the platform, we will notify them by email, or where that is not possible, by public notice.
Rights
A person whose personal data we hold may:
- Ask what we hold about them, and why.
- Ask us to correct anything inaccurate, or complete anything incomplete.
- Ask us to erase it, subject to the limits set out above.
- Nominate another person to exercise these rights on their behalf in the event of death or incapacity.
- Complain to us, and if unsatisfied, to the Data Protection Board of India.
We will respond within thirty days. There is no charge. We may ask for enough information to establish who is asking, and we will ask for no more than that.
Where a request concerns personal data findings or exposure information that we process on behalf of a customer organisation, we will refer the request to the relevant customer organisation and provide reasonable assistance in responding to the request, as the customer organisation acts as the Data Fiduciary in respect of that processing.
Contact
Write to Pooja Gupta, at grievance@cloudheal.com, or at Unit 101/B-1, First Floor, Raheja Plaza-1, LBS Marg, Ghatkopar West, Mumbai - 400086. We will acknowledge within seven working days and respond within thirty.
Changes to this notice
This notice is version V1.1, issued on 10 October 2026. Earlier versions are available on request. Where a change materially affects how personal data is used, we will tell affected customer organisations at least thirty days before it takes effect.