Privacy Policy

Who we are, and what this covers

CoreLoop is operated by Melange Oy, a company registered in Finland. Business ID / VAT number FI27760448. Registered address: Pitkäkalliontie 9, 01800 Klaukkala, Finland. For anything in this policy, write to support@coreloop.so.

CoreLoop is a business service. Our customers are businesses and they contract with us in a business capacity — sole traders, small firms, agencies, and larger chains. We do not offer CoreLoop to consumers.

Who is responsible for what. We are the controller of the personal data we hold for our own purposes: account and billing data, our marketing site, security, and running the platform. Where someone sends a message to a business through CoreLoop — an inquiry from a business's page, or an email to the address a business connected — that message belongs to the business's own inbox. The business decides what to do with it and is the controller of it. We transmit and store it on their behalf, and we apply our own security and anti-abuse controls to it.

This policy does not cover a customer's own website, the businesses listed on CoreLoop, or the AI agents that read CoreLoop. Those are other people's systems and other people's policies.

What we collect

Most privacy policies describe one kind of person: the account holder. CoreLoop touches the data of several kinds of people, and most of them never signed up for anything. They are all listed here.

Account holders and business owners.

• Identity, from our authentication provider: email address, first and last name, and profile image. Passwords and multi-factor secrets are held by that provider and never by us.
• Account settings: interface language, timezone, notification preferences, which notifications you have read, and when you were last active.
• Organisation membership and your role in it, plus ownership records when a company changes hands.
• Billing: your organisation's name, the billing email address, and an organisation identifier are sent to our payment provider, which returns customer and subscription identifiers we store. Card details go to the payment provider directly; we hold only a masked summary of the card. We never see or store a card number.
• An audit record of significant actions taken in the account, with free text scrubbed of emails and IP addresses before it is written.
• Anything you write into your profile, upload as a document or image, or type into a cancellation survey.

Visitors to our marketing site and signed-in app.

• Analytics that stores nothing on your device. We measure which pages are visited and which features are opened. Our analytics provider sets no cookie and writes nothing to your browser's storage. It does not receive your account identifier, your organisation, your name or your email address. To count a visitor once rather than once per page it derives a value from the request your browser already makes — the network address and browser details — using a secret that changes daily and is specific to this site, so the same visitor is a different value tomorrow and cannot be matched to a visit on any other site. Our basis is legitimate interests, and you can object — see Your rights.
• Our own record of which pages were read. Separately from the provider above, every page of our public site — this one included — sends us a small beacon that we store ourselves, in our own database. It sets no cookie and writes nothing to your browser. We keep three things: the page address with any query string removed; the host of the site you followed a link from, never the full address of the page you came from; and a value derived from the network address and browser details your browser already sends, mixed with a secret that changes every day, so the same visitor is a different value tomorrow and cannot be joined up across days. The network address and browser string themselves are never written down. These individual records are deleted after 30 days; what outlives them is a daily count per page.
• A few product events are recorded the same way, without an identifier — that an onboarding step was viewed, or that a setup task was marked done. Each carries at most a short label, such as which step it was.
• Error reports. If something breaks, a diagnostic report is sent to our error-monitoring provider. The report has fields that carry your identity — IP address, email address, username, cookies, query strings and sensitive headers — and we empty those fields before it leaves. What we cannot empty is the error text itself: an error message is free text written by whatever failed, and personal data can end up inside one. Error monitoring runs on every page — it sets no identifiers and stores nothing about you deliberately, but we would rather say so than let you infer otherwise.
• Bot protection during sign-up. Our authentication provider loads a challenge from Cloudflare. Whatever it collects from your browser goes to Cloudflare; we configure nothing and receive nothing back.
• Functional preferences kept in first-party cookies: appearance, interface language, and which sign-in method to offer you first. Your display currency is NOT among them — it is worked out per request from your connection and kept nowhere. The full cookie inventory is in our Cookie Policy.
• If you subscribe to our newsletter: your email address, language and where you subscribed from. Subscription is double opt-in — we send a confirmation and do nothing until you click it.

People who send an inquiry, or email a business through CoreLoop. These are members of the public with no CoreLoop account. They are the data subjects a policy like this most often forgets, so they get their own paragraph.

• Inquiries. A business's page carries a contact form, and an AI agent can send a message through the same channel on your behalf. Either way we receive your name and message, and — if you provide them — your email address, phone number and a subject line. Before storing them we strip out HTML, trim surrounding whitespace, and neutralise phrases that are known attempts to give instructions to a reading AI model, replacing each with a marker; a message that grows past the length limit as a result is then trimmed to fit. Otherwise the text is what you wrote. We store it in the notification we raise for the business and in the conversation thread that business sees, and we pass it to the business by email, with your address set as the reply-to when you gave one. On the web form, and only when you gave an email address, we also send you a copy.
• The contact and support form. Your email address, name, subject, message and any attachments become a support ticket. Your address is stored in full and indexed so we can find your history, and your name, address and message are also emailed to our own staff mailbox so a person sees them. We also run the subject and message through an AI model to sort and prioritise the ticket, which produces stored judgements about it — topic, urgency, tone, priority. Your email address and name are structurally excluded from what the model sees.
• Inbound email. If a business has connected an email channel, mail sent to it becomes a conversation: your address and display name from the From header, the subject, the body and attachments. Mail we cannot route to anyone is not stored at all — we hash a fragment of the address to raise a content-free alarm and discard the rest.
• Your IP address is never stored. We hash it to enforce anti-abuse limits, and the hash lives only in a short-lived cache. Inquiries are capped at three per day from one sender to one business, and fifty per day per business.

Visitors to a public business page.

• Public business pages set no cookies at all and load no product analytics. A page served on a business's own custom domain sets no CoreLoop cookies whatsoever.
• A page view sends us a small beacon: the business, the page language, how you arrived, what you clicked, and how long you stayed. It carries no cookie, no stored identifier and no full referrer, and the request is made without credentials.
• To count visitors without tracking them, we compute a hash of your IP address and browser string mixed with a secret that changes every day. The same visitor hashes to a different value tomorrow, so the value cannot be used to follow anyone across days. The raw IP address and browser string are never written down.

People named in content we crawl or a customer uploads. When a customer asks us to read their website, the pages we read routinely contain other people's personal data — staff names, direct dial numbers, photographs. CoreLoop has no field for staff, so anything of this kind that survives extraction lands as free text in the business's own profile. See Crawling and AI processing.

What we do not collect. We do not seek special categories of personal data. CoreLoop has no field that asks about health, biometrics, ethnicity, beliefs, or anything comparable. We cannot stop a free-text box from receiving whatever someone types into it, so please do not put such information in one.

Why we are allowed to do this

Under the GDPR every use of personal data needs a legal basis. Ours are these.

We do not rely on consent to run the service itself, and that is deliberate. Consent must be freely given and freely withdrawn. If consent were the basis on which we held your account data, withdrawing it would oblige us to stop serving a customer who is paying us — which helps nobody and is not what either of us agreed to. Performance of a contract is the honest description of what is happening, so that is the basis we use. Consent is reserved for the one thing that is genuinely optional: the newsletter. Withdrawing it changes nothing about your service.

Where we rely on legitimate interests you have the right to object, and we will stop unless we have compelling grounds that override your interests. See Your rights.

What we publish

This is the section to read twice. CoreLoop's purpose is to make a business findable and usable by AI agents. When a customer publishes their profile, it stops being private in every sense of the word.

Where it is served. A published profile is available through all of the following at once:

• The public business page at coreloop.so/your-name, and on your own domain if you connect one.
• A machine endpoint for AI agents (MCP) at a public address for your business.
• A second agent endpoint speaking the A2A protocol, and an agent card describing it.
• An llms.txt file — your whole profile as plain text, written for language models to read in one request.
• An embed configuration that lets an agent running inside a browser use your tools on your own website.
• The public directory: our /discover pages and a cross-business search endpoint agents can query.
• A sitemap and robots file for your page, so search engines find it.
• Any document you have marked public, at a public link (up to five).

CoreLoop also publishes a platform-level discovery document at /.well-known/mcp.json. It describes that CoreLoop offers agent endpoints and points to the directory; it contains no business's data.

What is in it. Business name, tagline, short and long description, category, primary city and country, every location's full street address, postal code and phone number, the business's contact phone, email address, website and social links, services with prices, currencies and durations, opening hours, cancellation and payment policies, accessibility information, owner-selected testimonials and rating, the languages the profile is offered in, and whether the business is verified. That whole estate is served through the public page, the agent endpoints and the llms.txt file, each in its own format. The public directory is the exception: a directory result is a summary — name, short description, category, city and country, rating, service count, verified status, available languages, and links to the page and endpoints. Addresses, phone numbers, email addresses and individual services are not in a directory result; an agent that wants them follows the link.

What is never published. Your own account email address is not the business's public contact address and is never served on any public surface. Nor is any billing data, any analytics, any crawl or AI-generation record, any verification or domain-setup detail, or any document you have not marked public. The agent endpoints do not read the tables that hold user accounts, memberships or audit records at all.

Who reads it, and what happens next. AI agents we neither control, vet, nor contract with can retrieve a published profile at any time. Once they have, we cannot see what they do with it. A copy may be cached, stored, indexed, summarised, translated, or fed into another system by parties we have no relationship with. Copies may persist beyond our reach, indefinitely.

Unpublishing stops us, not them. Changing a profile away from published takes it off every CoreLoop surface. It is not instantaneous everywhere: we clear the caches as part of the change, but a copy already cached can be served briefly, and the directory listing is removed by a job that runs shortly afterwards rather than in the same moment. Expect minutes, not hours. What unpublishing does not do, and cannot do, is recall a copy someone already took. There is no mechanism anywhere on the internet that can.

The controls you have, and exactly what each one does.

• Publication status. Only a published profile is served. Draft, unpublished and suspended profiles return an error to every agent surface, and only published profiles are ever cached.
• The protocol kill switch. You can switch off an individual protocol — the MCP endpoint, A2A, and so on. Note the default carefully: a protocol you have never configured is active. Switching off is an explicit act; not having touched it does not count as off.
• Directory listing. A published business is listed in the public directory by default. You can opt out, and the listing then disappears from directory search, from /discover and from the platform sitemap. Your own page and endpoints stay live.
• Individual tools. Each thing an agent can do — read your information, list your services, compare them, check your hours, read your reviews, send you an inquiry — can be switched off on its own. Switching off the inquiry tool takes effect immediately, because that switch is read live rather than from a cache.

We do not sell personal data. We have never sold it, we run no advertising, and we disclose nothing to data brokers. That sentence on its own would be misleading for a product like this, so here is the other half: we publish, to the entire internet and free of charge, whatever a customer chooses to publish. Not selling it is not the same as keeping it private. Both statements are true and you need both.

Crawling and AI processing

When a customer asks us to build a profile from their website, we fetch that website and send what we find to an AI model to structure it. Here is what that involves.

The crawl. We fetch the website address the customer nominates, using a third-party crawling service. By default we read up to ten pages. Before fetching, we check that the address resolves to a public host and refuse private and internal network addresses.

The extraction, and what it asks for. The page text is cleaned of prompt-injection patterns and sent to Anthropic's API to be read and structured. The instruction we give the model explicitly asks it to find the phone number, email address, street address, city, postal code and country. Our cleaning step removes attempts to hijack the model; it removes no email addresses, phone numbers, names or addresses, because the extraction is meant to find them. The practical consequence is worth stating flatly: any personal data published on the nominated website reaches Anthropic verbatim, including personal data belonging to people other than the customer.

The same applies to documents a customer uploads for extraction, and to profile text we machine-translate into other languages. Support tickets are also read by a model, but only the subject and body — the requester's email address and name cannot reach it.

What we keep. We do not store the crawled pages. What survives a crawl is: a record of the crawl itself (status, the address crawled, timings, page count, any error), a fingerprint of the cleaned text, the model's structured output, and — on the first crawl only — the extracted fields written into the profile. Separately, the cleaned page text is passed to our background-job platform as job data, so it exists there as job state for a period that platform's own terms govern rather than ours. Crawl records have no expiry of their own; they are deleted when the organisation is deleted.

We do not build or train AI models. We use third-party model APIs to read and structure content. What those providers may do with what we send them is governed by their terms for their API, not by a promise we can make on their behalf.

Generated text can be wrong. A profile built this way is a model's reading of a website. It can be incomplete, out of date, or simply mistaken. Check it before you publish it, and tell us at support@coreloop.so if something about you is wrong on a CoreLoop page.

Third-party AI agents

CoreLoop's agent endpoints are public and unauthenticated by design. That is what makes an agent able to use them without a business having to integrate with anybody. It also means we have no gate to put anyone behind.

We do not vet, control or contract with the agents that call. We do not know who operates them, we have no agreement with them, we cannot compel them to behave, and we cannot withdraw information they already hold. If an agent misrepresents a business, we can correct what we serve. We cannot correct the agent.

We cannot promise an agent will represent a business accurately. An agent may paraphrase, summarise, translate, mix a profile with other sources, serve a stale cached copy, or get it wrong. We publish accurate structured data and we sanitise the free text we serve so it cannot be used to manipulate a reading model. Everything downstream of that is outside our control.

What we log when an agent calls. We record which tool was called, the protocol used, response status and timing, a coarse platform label (one of ChatGPT, Claude, Gemini, Copilot, or unknown), and a hash of the caller's browser string. On a business's own agent endpoint we also record the arguments the agent sent, truncated to 1,000 characters — with one exception: the contents of an inquiry are deliberately never written to that log, because they carry the sender's own data.

IP addresses are never stored raw here either. The per-business endpoints derive their caller hash from the browser string alone. The cross-business directory endpoint derives one from the caller's IP address using a secret that rotates daily, so the same caller cannot be recognised the next day.

Who can see it. A business can see its own interaction records. Platform staff at the highest access level can see them across businesses, for support and abuse investigation. No screen anywhere renders the caller identifier itself. Raw records are deleted after 90 days, leaving only daily counts.

Almost nothing an agent can do writes anything. Every tool except sending an inquiry only reads, with one bounded exception in the page: on a form you have approved, an assistant can fill in details the visitor already gave it, and only after the visitor confirms on the page — CoreLoop never submits the form. The in-browser embed does not expose the inquiry tool at all, because a write that any in-browser agent could trigger without a confirmation step is a higher-risk surface than we want.

Who else processes data for us

We use the following providers to run CoreLoop. Each row states what a provider does for us and what personal data reaches it, and we use each provider for that purpose and no other.

Operational alerts. We send platform alerts to a Slack channel. They carry counts, rates, and internal reference numbers — a support ticket's identifier, a background job's identifier, the name of an error type. They never carry names, email addresses, message content, or anything else that identifies a person to someone reading the channel. Keeping them that way is an operating rule we hold ourselves to, not something the channel enforces.

Built but not switched on. Some connectors exist in the product without being active, and no customer data flows to them. We will update this list before any of them begins processing personal data.

Beyond this list we disclose personal data only where the law requires it, or to professional advisers under a duty of confidence. We do not sell personal data and we do not disclose it for advertising. Separately from disclosure, we publish what a customer chooses to publish — see What we publish.

How long we keep things, and how deletion works

We only state a period here where a scheduled job actually enforces it. Where nothing enforces a period, we say that instead of inventing one.

Deleting an account is not the same as deleting a company. Which one you are asking for decides what actually happens, so we describe them separately.

• Deleting a company. Its public page and every agent endpoint go dark immediately, and the company and everything belonging to it are marked for permanent deletion.
• Deleting your account, where you are the only member of your company. The company goes with the account and is marked for deletion alongside it.
• Deleting your account, where you are a member of a company you do not own. Your membership ends and your own user record is deleted. The company itself is untouched — it keeps running, and the data it holds stays with it.
• Deleting your account, where you own a company that still has other members. We refuse. The request is blocked until you transfer ownership to someone else or the other members leave, because deleting the account would otherwise orphan a company other people are working in. Transfer ownership from your settings, then delete.

Where something is marked for deletion, there is a seven-day reversible window. The data is kept for seven days. A job runs every night at 04:15 UTC and permanently erases anything past that window.

Inside those seven days we can restore it, on request to support — there is no self-service undo, and a restored profile comes back unpublished. It is never automatically re-published; you decide whether to publish it again. After seven days, restoration is not possible for anyone, including us.

What the permanent erase does. It removes your stored files and documents, clears cached data and counters, releases any custom domain, cancels the subscription with our payment provider, deletes the organisation at our authentication provider, deletes support attachments, and then deletes your records from our database in a single transaction. External systems are purged before the database, so a failure mid-way can be retried rather than leaving data stranded somewhere we can no longer find it.

Backup copies of uploaded files. Where we hold a backup copy of a file you uploaded — kept so that a file lost to an accident can be brought back — the permanent erase does not reach into it directly. Instead the copy expires. Every backup copy is deleted thirty days after it was taken, and once a file has been erased no new copy of it is ever made, so the last backup copy of an erased file is gone within thirty days of the erasure. A scheduled job does the deleting, and it runs every night whether or not new copies are being taken.

What the permanent erase does not reach. It is a purge of our own database and of the providers listed above where we hold a handle to delete: files, cache, domain, subscription, authentication. It does not reach every provider. Our payment provider keeps the customer and billing records behind the cancelled subscription, which it is required to retain for tax and accounting purposes. Our analytics, error-monitoring, background-job and email providers hold their own copies — job payloads, error reports, delivery and bounce records — and the erase does not send them a deletion instruction. Ask us at support@coreloop.so if you want data removed from one of those and we will do what we can with them.

Two things deliberately survive on our own side. The security audit log is append-only and cannot be rewritten; instead of deleting entries we remove the link to your organisation, so what remains no longer identifies it. And we keep a record that the deletion happened — status and timestamps, no personal data — for 180 days, so we can answer a question about it later. Beyond those, we keep anything the law independently requires us to keep, for as long as it requires.

Periods a scheduled job enforces.

Data with no fixed period. Notifications, conversations and their messages, crawl records, uploaded media and documents, daily analytics rollups and cancellation survey answers have no time-based expiry. They belong to the company that holds them, are kept for as long as that company exists, and are erased when the company is deleted — not when an individual member leaves or deletes their own account. The security audit log is kept indefinitely and is disconnected from your organisation on deletion rather than removed, as described above.

Newsletter records. A confirmed subscriber is kept until they unsubscribe or ask for erasure. When you unsubscribe we keep the record marked as unsubscribed rather than deleting it, so that a later re-subscription cannot silently revive a consent you withdrew.

What you can do yourself, without asking us.

• Delete your account.
• Delete your company, if you own it.
• Leave a company, or transfer ownership of it to someone else.
• Preview exactly what deletion will remove, before doing it.
• Delete individual integrations, images, documents, locations, services and scheduled reports.
• Change your cookie choice, and unsubscribe from the newsletter.

What needs you to contact us.

• Restoring anything inside the seven-day window.
• Deleting an account that still owns a company with other members in it. We refuse that one deliberately, so a company is never orphaned by one person leaving. Transferring ownership is something you do yourself, in your settings; come to us only if that is not possible.
• Any export of your data — there is no self-service export today.
• Erasing data tied to an email address that has no account: we can erase every support ticket, message and attachment linked to that address, and its newsletter record.

How we protect it

These are the measures CoreLoop actually implements, not a list of things that sound reassuring.

• Separation between businesses, enforced twice. Every record that belongs to a business carries its organisation identifier. The database enforces row-level security with a default-deny rule on every table, and the query layer refuses any tenant query that does not carry an organisation identifier. Looking up a record by its identifier verifies ownership first, and a mismatch returns “not found” rather than “forbidden”, so an identifier cannot be used to probe for another business's records.
• Encrypted credentials. The long-lived secrets for connected business systems are encrypted with AES-256-GCM under a dedicated key before they are stored, and exist in plain form only inside the code that uses them.
• Signed webhooks. Every incoming webhook is signature-verified before it is processed — HMAC-SHA256 for integration callbacks, and each provider's own verification for authentication, payment and email events.
• IP addresses truncated or hashed before they are written. No raw IP address is stored anywhere in CoreLoop. Where an IP is needed for an audit trail it is truncated first; where it is needed to count or limit, it is hashed. Free text bound for the audit log is scrubbed against a list of sensitive field names and against email and IP address patterns.
• Rate limits on the surfaces that need them. The agent endpoints, the directory, the inquiry channel, uploads, the contact form and the administrative surfaces are rate-limited — per business, per sender, per recipient, or per administrator as the surface requires. Reading a public business page is not itself rate-limited; it is a cached public page, and the endpoints behind it are. The limits protecting the inquiry channel fail closed: if the limiter itself is unavailable, the message is refused rather than let through unchecked.
• Hardened administration. Staff access requires multi-factor authentication, can be restricted to an address allowlist, and demands a fresh step-up challenge before any sensitive action. Every such action is written to a separate administrative audit log.
• Browser-level protections. Strict transport security, a content security policy with per-request script nonces on the signed-in application, a stricter policy again on administrative pages, and the standard protective header set on every response.
• Scrubbed error reports. Diagnostics leaving our systems have their IP address, email, username, cookie, query-string and sensitive-header fields emptied first. The free-text error message is not a field we can empty, so personal data appearing inside one can travel with the report.

Traffic to and from CoreLoop is encrypted in transit. Beyond the credential encryption described above, data at rest is protected by the storage platforms we use, under their terms. We hold no security certification and we do not claim one. No system is perfectly secure, and we will not pretend otherwise.

Where data is processed

What we can state precisely. Our database, our file storage and the application servers that run CoreLoop are all located in Ireland. Email is sent and received through our provider's EU region. Error monitoring runs in Germany. Analytics is collected by the same provider that hosts the application; we do not claim a processing region for it, because we cannot show you one.

What we will not overstate. Requests reach those servers through a worldwide delivery network, so the location that first receives a request — and therefore sees its IP address and headers — is the one nearest you, which will often be outside the European Economic Area. Several of the providers listed above are also established outside the European Economic Area or may process data outside it, including the providers we use for background jobs, AI extraction and translation, crawling, payments, authentication, caching and bot protection. We are not going to tell you that all processing happens inside the EEA when we cannot show you that it does.

The contractual position, stated carefully. We engage each provider under the terms published by that provider and accepted when we opened the account. Those terms commonly include the provider's own data-processing terms, and for several providers they do. We are working through the providers one by one to record, for each, which transfer safeguard actually applies, and we will set out the mechanism per provider here once that review is complete. We would rather leave this paragraph thin than name an instrument we have not verified.

The technical measures that travel with the data wherever it is processed are described in How we protect it.

If you need this detail for a supplier assessment before that review finishes, write to support@coreloop.so and we will share what we hold for the providers you ask about.

Your rights

If we hold personal data about you, you have the following rights. They apply whether or not you have a CoreLoop account.

• Access — a copy of the personal data we hold about you, and an explanation of what we do with it.
• Rectification — correction of anything inaccurate, and completion of anything incomplete.
• Erasure — deletion, where we have no overriding reason to keep it.
• Restriction — a pause on our use of it while a dispute about it is resolved.
• Portability — the data you gave us, in a structured, machine-readable form, where we process it by consent or under our contract with you.
• Objection — to any processing we base on legitimate interests, including our security and telemetry processing. We stop unless we have compelling grounds that override your interests.
• Withdrawal of consent — for the newsletter, at any time, from the link in every message. Analytics is not consent-based (nothing is stored on your device and no identifier of yours is sent), so the right to use against it is objection, above. Withdrawal does not undo processing that already happened lawfully.

How to exercise them. Email support@coreloop.so and say what you want. Several things you can simply do yourself — see the self-service list in How long we keep things. There is no self-service export today, so a portability or access request is handled by us on request.

Verifying who you are. We will ask for enough information to be satisfied that the request is yours, and no more than that. Usually this means writing from the address we already hold. If we genuinely cannot identify you from what you give us, we will say so and ask for more; if we still cannot, we may be unable to act on the request, and we will tell you why rather than leaving it unanswered.

How fast. We respond within one month of receiving the request. If a request is complex, or you have made several, we may extend that by up to two further months — and we will tell you inside the first month that we are extending, and why.

If we say no. We will tell you which right we are refusing, the specific reason, and what you can do about it: complain to a supervisory authority, and seek a remedy through the courts. We will not refuse a request silently or by not replying.

Complaining. Our lead supervisory authority is Finland's Office of the Data Protection Ombudsman (Tietosuojavaltuutetun toimisto), tietosuoja.fi. You may complain to them, or to the authority in the country where you live or work. We would rather you told us first so we can fix it, but that is your choice, not a condition.

If you are in the United Kingdom

We serve customers and their visitors in the UK. Where UK data protection law applies to your personal data, this policy applies with the following changes.

• References to the GDPR read as references to the UK GDPR and the Data Protection Act 2018. The legal bases in Why we are allowed to do this have the same numbering and the same meaning under the UK GDPR.
• Your supervisory authority is the Information Commissioner's Office (ico.org.uk). You can complain to the ICO about anything in this policy or anything we have done.
• Where UK personal data is processed outside the UK, Where data is processed describes what we can and cannot state about it. Ask us and we will tell you what arrangements apply to a particular provider.
• Your rights, our response times, and our refusal and appeal process are as set out in Your rights.

United States state privacy laws

This section applies to residents of US states with comprehensive privacy laws. CoreLoop is a business service, so most personal data we hold about a US resident is held in a business context — a customer's staff, a person who contacts us on behalf of a company, or someone who sends an inquiry to a business. California's law extends its rights to people in exactly that position, so we apply this section to business contacts as well as to anyone else.

What we collect, in the categories these laws use. Identifiers (name, email address, account and organisation identifiers); commercial information (subscription and billing records); internet or network activity (page views and agent interaction records); geolocation only at the coarse level of a display currency inferred from your connection; and the contents of messages you choose to send us or to a business through us. Sources are: you, the business you work for or contacted, our service providers, and the website a customer asks us to read. Our purposes, and who else receives it, are set out in the sections above.

Your rights under these laws.

• To know what we collect, why, and who receives it — this document.
• To access a copy of it.
• To correct it if it is wrong.
• To delete it.
• To opt out of sale or of sharing for advertising — which we do not do, so there is nothing to opt out of.
• Not to be treated worse for exercising any of these. We do not offer a different price or a worse service to anyone who does.

Exercise any of them by emailing support@coreloop.so. We verify identity as described in Your rights. You may use an authorised agent; we will ask for proof of their authority. We do not seek sensitive personal information, and CoreLoop has no field that asks for it.

If there is a breach

If a personal data breach occurs, we notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to people's rights and freedoms. This is our obligation under Article 33 of the GDPR, and the corresponding provision of the UK GDPR.

Where a breach is likely to result in a high risk to affected individuals, we tell those individuals without undue delay, in plain language: what happened, what data was involved, what we are doing about it, and what they should do. That is Article 34.

Where the affected data is one we handle on a customer's behalf, we notify that customer without undue delay so they can meet their own obligations to the people concerned.

We keep an internal record of breaches, including those we assess as not requiring notification, and the reasoning for that assessment.

Children

CoreLoop is a service for businesses. It is not designed for, marketed to, or directed at children, and an account requires a business relationship with us.

We do not knowingly collect personal data from children. If you believe a child's personal data has reached us — through an account, an inquiry, or a business profile — tell us at support@coreloop.so and we will delete it.

Changes, and how to reach us

We update this policy when the product changes, because a policy that describes an older version of the product is worse than no policy. The version number and effective date at the top of this page tell you which one you are reading.

A change takes effect when we publish it, under a new effective date and version number. We do not currently email account holders in advance of a change to this policy, and we would rather say so than promise a notice we do not send. If you want to know when this policy changes, check the effective date at the top of the page.

Contact. Melange Oy, Pitkäkalliontie 9, 01800 Klaukkala, Finland. Business ID / VAT FI27760448. Email support@coreloop.so — that address reaches us for every privacy, data-protection and legal question, and it is the only address you need.

Related documents: our Terms of Service and our Cookie Policy.

Supervisory authority. Office of the Data Protection Ombudsman (Tietosuojavaltuutetun toimisto), Finland — tietosuoja.fi.