Privacy Policy

Sodasoft, a company registered in Wyoming with its address at 30 N Gould St, Sheridan, WY 82801, United States, operates Decimio (decimio.com). In this policy "we", "us" and "Sodasoft" mean that company, and "you" means whoever is reading: a customer, someone who has asked for access, or a person whose business contact details we hold and who never gave them to us. The last of those is the reader we have tried hardest to write for, because you are the one who has heard the least from us.

We have tried to describe the system we actually run rather than the one a policy of this kind usually describes. Where our software does something a reader would not expect, this policy says so in the same words we would use internally.

The two roles we act in

Which role we act in depends on whose data it is, not on which button produced it.

For personal data about the people your searches, uploads and enrichments concern - your prospects, the people your lists name, everyone our own search and enrichment tools find for you - we are a processor and you are the controller. We act only on your instruction: what you searched for, what you asked us to enrich, what purpose you told us it was for. A person's record belongs to the workspace whose instruction produced it and to no other; it is never copied into a store we control, never combined with another customer's data, and never shown to any other customer. This matches sections 5 and 11 of our Terms and Conditions and the Data Processing Agreement.

For data about businesses and companies as such - a company's name, domain, headcount, industry, the fact and date it was founded - we are the controller. A company is not a person and this is not personal data, so no data protection law attaches an individual's rights to it. We collect it ourselves, from suppliers and public sources, hold it in a shared store, and may show the same company fact to more than one customer.

For your own account, billing and security data - your name, your sign-in email, your workspace's credit ledger, the IP address behind a sign-in or an access request - we are an independent controller. We process it to run your account, bill you, and keep the service secure, and not on anyone's instruction but our own.

For the personal data your workspace's own instructions produce, you are responsible for having a lawful basis, for telling the people concerned whatever notice the law requires, and for handling their requests. Our Terms and Conditions say so, and you warrant it to us when you use the service.

What personal data we process

About people who use Decimio

• Access requests. Name, business email address, company name, any message you write, and the IP address the request came from. We keep the IP address because it is what stops the form being abused.
• Account and sign-in. Name, email address, which workspaces you belong to, your role, whether your account is active, and when you last signed in. Sign-in is by emailed link, so we hold no password. A signed-in browser has a server-side session recording your user, your workspace, when the session expires and when it was last used.
• Usage and billing. The credit ledger for your workspace, the jobs you ran, what was delivered, what was charged, and a log of which values were shown to your workspace and when.

About business contacts and companies

These are people in a professional capacity, and companies. We group the fields into classes, because the class is what governs how long we believe a value and how long we may serve it. A row about a person is held in the workspace whose instruction produced it, where we are the processor; a row about a company as such is held in the shared store described above, where we are the controller.

• Person identity. Name, professional profile URL.
• Employment. Job title, seniority, current employer.
• Work contact verification. Work email address, company email address, whether it verified, how, and when.
• Personal contact. Mobile telephone number, personal email address. See the note below: these are switched off everywhere by default.
• Rich profile. Summary, about text, described experience.
• Company identity, firmographics and metadata. Company name, domain, website, company profile URL, headcount, size band, industry, company type, headquarters city, region and country, year founded.
• Public activity. A latest public post, and news or media items about a company.
• Our own computed score. A relevance score we calculate from the fields above against the ideal profile one customer has defined. It is arithmetic over fields that customer chose to rank on, not a judgement about a person, and it is held in that customer's own workspace rather than in the shared store.
• Provenance, on every row. Which source told us, the source's own request identifier, when the source said the fact was true, when we acquired it, a confidence value, the verification verdict and method, and the licence terms that applied when we stored it.

We do not seek and do not knowingly store special category data under Article 9 of the GDPR: no health, racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic or biometric data, sex life or sexual orientation. Nothing in our field list asks for any of it. A free text field such as a professional summary could in principle contain something a person wrote about themselves publicly; we do not index or use it for that.

Personal contact data is denied everywhere by default. Mobile numbers and personal email addresses are refused in every country unless an administrator has affirmatively recorded a jurisdiction where they are permitted, together with the basis for that decision. This is enforced in the software, before any money is spent, not applied by hand afterwards.

Where the data comes from

If we hold data about you and you never gave it to us, it reached us from one of these categories of source.

• Commercial data suppliers under contract with us, who provide business contact and company data.
• Public registers and other publicly available sources, including official company registers and public professional and company web pages.
• Verification services that test whether an email address or telephone number is deliverable, and return a verdict rather than new personal data.
• Our customers, whose uploaded lists determine which people and companies we then look up, and who may report to us that a value is wrong.

We give categories rather than names. Which suppliers we use is the commercial core of what we sell, and we do not disclose it to customers or on this page. We will name a supplier where the law requires it of us and to a regulator on request, and an enterprise customer negotiating a data processing agreement should raise it with us directly.

Why we process it, and on what legal basis

A processor does not need its own Article 6 basis for the data it processes on a controller's instruction - the customer's basis is the one that matters, and section 6 of our Terms makes the customer warrant that they have one. The bases below are Decimio's own, for the processing we carry out as controller.

• To run your account and provide the service you bought. Article 6(1)(b) of the GDPR: performance of a contract with you.
• To build, maintain and provide the shared store of company and business data, including providing the same company fact to more than one customer. Article 6(1)(f): our legitimate interests and those of our customers in identifying other businesses. This does not extend to a person's data, which we hold only on a customer's instruction, as their processor.
• To keep the accounting, ledger and audit records that let us answer a billing question or a data complaint. Article 6(1)(f), and Article 6(1)(c) where a record is required by law.
• To keep the service secure and to prevent abuse of an unauthenticated form. Article 6(1)(f), narrowly: an IP address behind a sign-in link request or an access request, used only to rate-limit that request. Summarised below.
• To answer a suppression, objection or other rights request, and to keep it honoured afterwards. Article 6(1)(c), and Article 6(1)(f) in keeping a record that the request was made so that it cannot be undone by accident.

We do not rely on consent for any of the above, and we do not claim you gave it. We do not use your data for automated decision making that produces legal or similarly significant effects about you.

Our legitimate interests, in summary

Where we rely on Article 6(1)(f) as controller, we are required to weigh our interest against the rights of the person concerned. This section used to summarise an assessment covering the whole store of business contact data, because we used to be its controller. We no longer are: a person's data is now held only on a customer's instruction, as their processor, and it is the customer's basis that governs it, not ours. This is the short form of the narrower assessment that remains ours to make.

• The purpose. Preventing an unauthenticated form - requesting access, or asking for a sign-in link - from being flooded, which would exhaust our mail quota or fill a queue a person then has to read. GDPR Recital 49 names processing for network and information security as capable of being a legitimate interest.
• Why it is necessary. Our web tier keeps no memory between requests, so a count has to live in the database to mean anything, and a lighter alternative such as a third-party CAPTCHA would add a new processing activity rather than avoid one.
• The balance, and what we do to keep it. Only an IP address and a timestamp are held, for an hour's window, and only to decide whether to accept one more request. It is not looked at by a person in the ordinary case and is not combined with anything else we hold about you.
• What we accept is against us. Neither table has a configured retention period today, so the address is held longer than the purpose needs. That is recorded as unresolved in the fuller assessment, not smoothed over here.

You may ask us for the fuller assessment by writing to privacy@decimio.com.

Who we disclose personal data to, and the fact that we sell it

We should be plain about this, because a euphemism here would be the one thing in this policy a reader could fairly call misleading.

We sell access to business contact data. When your workspace instructs us to search for or enrich a named person, and we find them through our own sources, we charge you for that and hand you their details. If and when the CCPA applies to Sodasoft, providing personal information about a business contact for consideration is a sale as that Act defines it, and it is why the California section below exists. We describe ourselves that way rather than argue about it, and the section holds whether or not the Act reaches us today.

What changed is who else that value goes to. A person's row belongs to the workspace whose search or enrichment produced it, and only that workspace. We do not resell the same person's data a second time to a different customer, and we do not hold it as our own asset once your instruction is answered - this is enforced at the database itself (ck_observation_person_needs_a_workspace), not only by policy, and tests/test_cross_tenant_sale_stays_closed.py fails our own build if that ever stops being true. The sale, where the CCPA reaches it, is to the one customer whose instruction produced it.

Company and business data is different: we do sell the same company fact to more than one customer. When a customer asks about a company and we already hold a current answer, we charge the asking customer the ordinary price and do not repeat the lookup. Whether we may do that with a given value depends on the terms of the source it came from: where a source's terms do not permit reuse, the value is used only for the customer whose request produced it, and this is enforced in software rather than by policy. This is data about a business, not a natural person, and our reviewed position, as of 12 September 2026, is that it falls outside "personal information" as the CCPA defines it, for data that is genuinely about the entity and nobody in particular -- the service-provider/contractor model under written contract is not a sale of it. That position has a limit: the B2B exemption that used to cover business contact data expired at the end of 2022, so a named person's own title, work email or phone number is personal information under the CCPA regardless of whose company they work for, and is covered by the section above, not this one. This is the owner's own review, not counsel's formal sign-off, and the California section below covers the practice out of caution regardless of where this question ultimately lands.

These are the categories of recipient.

• Our customers, who are businesses buying access to company data, and who receive the results of the searches and enrichments they instruct us to run about a person on their own behalf. They receive it on screen and in exports they download.
• Infrastructure and service providers acting for us under contract: application hosting, managed database hosting, transactional email delivery, and payment processing when card payment is enabled. They process on our instructions and may not use the data for their own purposes.
• Data suppliers and verification services, to whom we send an identifier in order to ask a question about it. Sending an email address to be verified is itself a disclosure, and we count it as one.
• Professional advisers, such as lawyers and accountants, under a duty of confidence.
• Authorities, regulators and courts, where we are required to disclose or where we need to establish or defend a legal claim.
• An acquirer, if the business or the relevant assets are ever sold, subject to this policy continuing to apply.

A current list of the service providers we use is available to account holders on request. We do not publish the identity of our data suppliers, for the reason given above.

A copy that has left us has left us. When a customer exports a list, that file is on their computer. If you later ask us to stop, we stop, across every customer and every future request. We cannot reach into a spreadsheet a customer downloaded last month. What we can do, and do, is keep a record of which values were shown to which customer and when, so that we can tell you who to ask.

International transfers

Sodasoft is a United States company and we operate the service from the United States. If you are in the European Economic Area, the United Kingdom, the United Arab Emirates or anywhere else outside the United States, personal data about you is transferred to the United States and processed there, and our service providers may process it in other countries where they operate.

The United States has not been recognised as offering an equivalent standard of protection generally. Where a transfer needs a mechanism under Chapter V of the GDPR, we rely on the European Commission's Standard Contractual Clauses, together with the United Kingdom's International Data Transfer Addendum where the United Kingdom GDPR applies, and on the safeguards recorded in our contracts with the suppliers and service providers involved. Customers in the European Economic Area or the United Kingdom who need those clauses as part of a data processing agreement should ask us and we will provide them.

Our representatives in the EEA and the United Kingdom

Sodasoft is established in the United States. Article 27 of the GDPR requires a controller outside the Union to appoint a representative inside it, and the United Kingdom requires its own under the UK GDPR. They are two separate appointments, because the United Kingdom left the EU regime, and this section is written from the appointment records themselves rather than from a sentence somebody typed once.

Appointing a representative does not change where we process data, and deciding to process somewhere does not appoint one. They are two records and we keep them apart deliberately, so that neither can be quietly assumed from the other.

How long we keep it, and what keeping means here

This section describes what our software does rather than what a retention policy would like it to do, because the two are not the same and the difference matters to you.

Observations are append-only

Once an observation is written it is never edited. The database itself refuses that, without exception and for everyone including us. We built it that way so that a complaint about one person can always be answered with where each value came from, which is impossible if the evidence can be rewritten, and so that our accounting cannot be quietly altered.

An observation can be destroyed, and that is a different thing from being edited. Append-only exists to stop history being rewritten; an erasure does not rewrite history, it ends a row's life and records that it did. So deletion has exactly one lawful form: the database will destroy a row only when a permanent receipt of the erasure is created in the same instant, and it checks that for itself rather than trusting the software. No receipt, no deletion. The receipts themselves can never be edited or removed, because they are the authorisation.

A retention window now destroys a value, not merely stops it being served. We record a retention window for each class of field, and for a given supplier contract where that contract is shorter; the shorter of the two applies. A value past its window is refused at the single place where data passes from our store to a customer, and it is then physically destroyed by a sweep that runs continuously, along with the re-checks and the entitlements that pointed at it.

A window nobody has decided is not a window we enforce, so those classes are counted and their oldest value is aged on our own compliance screen rather than being quietly immortal. We would rather show you the gap than let it sit unmeasured.

At the time of writing, one retention window is configured: personal contact data, meaning mobile numbers and personal email addresses, at 365 days. Other classes have no window recorded, which means no limit has yet been decided for them rather than that a limit of forever has been chosen.

Freshness is a different clock

Separately from retention, each class of field has a period after which we no longer treat a value as current. This governs whether we will sell you a value as accurate today, not how long it is kept. These are the defaults; a supplier contract, a jurisdiction, the class of data or a customer plan can shorten them.

Everything else

• Account and workspace data. Kept while the account is open.
• Sessions. A signed-in session expires 14 days after it is created, and signing out ends it immediately.
• The log of which values were shown to a workspace. One entry per value, per workspace, per channel, per day. Deleted when that workspace is erased.
• Access requests. Kept while we consider the request and afterwards as a record of who asked. We have not yet fixed a period; we will delete an access request on request, and we are setting a standard period as part of this review.
• Accounting records. Kept for as long as tax and company law require, in a form that survives the account being erased. See below.

What happens when a customer leaves

When we erase a workspace we delete what is genuinely the customer's: their lists, their uploaded rows, their credit ledger, their entitlements, their sessions and the log of what they were shown. Our own cost records keep every figure and lose the identity of the workspace they belonged to, so that the books remain reconcilable and no longer name the customer. We write a record that the erasure happened, who asked, and why.

A person's observations leave with the workspace; a company's do not. Every observation about an identifiable person that a workspace's own searches and enrichments produced belongs to that workspace, and erasing it physically deletes those rows - the value and the identifier are removed, not merely the workspace's name on them - and writes a keyed receipt so the fact of the deletion can be proven afterwards. Observations about a company as such are not deleted, because they are not personal data and are not the departing customer's to begin with; they are ours, held in the shared store described above. Either way, your own route as the person concerned does not depend on any customer leaving: the section below is the one that applies to you, and it works whether or not the workspace that looked you up still exists.

Your rights

If you are in the European Economic Area or the United Kingdom you have the rights below under the GDPR. If you are elsewhere we will apply them to you as well, as a matter of practice, except where a specific law gives you something different. The California and United Arab Emirates sections add to this.

• Access. A copy of the personal data we hold about you, where it came from by category, who it has been disclosed to by category, and how long we expect to keep it. We can search our store by email address, by domain, by professional profile handle and by our own internal key for a person.
• Rectification. Tell us a value is wrong and we will correct it. Because observations are append-only, a correction is recorded as a newer and better observation which then becomes the value we serve; the older one stops being used but remains as part of the record of what we were told and by whom.
• Erasure. We suppress you first, permanently and immediately, and then destroy the observations we hold about you, the confirmations that re-checked them, and the copies sitting in our customers' own lists. The suppression is written before anything is destroyed and outlives it, so a failure part way through leaves you protected rather than exposed. Read the paragraph below for what survives and why.
• Restriction. We will stop serving your data while a dispute about it is resolved. This is the same mechanism as suppression and it works immediately.
• Portability. Where it applies, we will provide the data you gave us in a structured, machine-readable format. Note that most of what we hold about a business contact was not given to us by them, so the right rarely reaches it.
• Objection. Because we rely on legitimate interests, you may object at any time. Where the objection concerns direct marketing, and prospecting is what our customers use this data for, we must stop. We do not ask you for a reason and we do not weigh your objection against our interest.
• Complaint. To us, and to a supervisory authority. See the last section.

How to exercise any of them. Write to privacy@decimio.com. Tell us the email address, telephone number, professional profile URL or company domain we would know you by, so that we can find you: we cannot search for a name alone with any accuracy. We will respond within one month, and will tell you if we need longer. We may ask for enough information to be satisfied the request is really yours, and we will not use what you send us for anything else. Requests are handled by a person reading an email; there is no self-service portal today, and we would rather say so than imply a button that does not exist.

Objection, suppression, and what erasure really does

This is the most important paragraph on the page for anyone who wants us to stop.

When you ask us to remove you, we add you to a suppression list. It works like this, and the description is literal.

• It is keyed on you, not on a record. A suppression is an identifier: an email address, a company domain, a professional profile handle, or our own internal key for you. Any one of them that matches suppresses everything we hold about you. We normalise identifiers the same way our importer does, so a different capitalisation or a trailing slash is still you.
• It holds across every supplier. A suppression is not attached to the source that told us about you, so a different supplier telling us the same thing tomorrow does not reintroduce you.
• It survives a customer re-importing you. If a customer uploads a list with you on it, we refuse to look you up before we spend anything, and refuse to hand over anything we already hold.
• It applies to customers who already paid. A customer who bought the right to see your details before you objected stops seeing them. Having paid does not outrank your objection.
• It is checked at the only door. There is a single place in our software where data passes from our store to a customer, and the check is there, so it cannot be missed by a feature written later.

What suppression does on its own. Suppression stops your data being served. It does not by itself destroy anything, which is why an erasure request is answered with both: the suppression holds the door shut for good, and the destruction follows behind it. The suppression outlives the data it suppresses, so erasing you does not quietly reopen the door to buying you again next week.

What an erasure leaves behind. Counts, what was charged, and a one-way digest of each identifier. The digest lets whoever holds the identifier confirm that the erasure happened; to everybody else, ourselves included, it is noise. That is the only way we know to prove a destruction without keeping what was destroyed. We also keep the record of who your details were disclosed to, because this document promises you that answer.

What no erasure can do. It cannot recall a copy a customer exported to their own computer before you asked. If you want to know which of our customers were shown your details and when, ask us and we will tell you what our log records.

A suppression can be lifted only deliberately, and it is recorded. If we ever remove one, the reason and the person who did it are written down permanently.

If we got your data from somewhere else

Article 14 of the GDPR applies when personal data is not collected from the person it is about, which is the normal case for the business contact data a customer's search or enrichment produces. It requires the controller to tell you who they are, what is held, why, on what basis, who it is disclosed to, whether it goes abroad, how long it is kept, what rights you have, and from what categories of source it came.

We are the customer's processor for this data, not its controller: the customer decides to look you up and we act on their instruction. That does not mean nobody owes you this notice, and it does not settle who does - the customer, us, or both depending on how a given source is classified is a question our own internal record leaves open (docs/legal/article-14-assessment.md). What we do regardless of how that question is answered: we publish this page, so a person who has never heard of Decimio can find out what categories of data our customers' instructions can produce about them and how to object; and we do not email every person a customer's instruction concerns, because doing so would itself be an unsolicited contact of exactly the kind our Terms require a customer to justify before they make it. Article 14(5)(b) is the provision this page stands in for individual notice under, whichever party the duty ultimately falls on: it permits appropriate measures, including making information publicly available, in place of notice at the scale this would otherwise require, and this page and the objection route below it are those measures.

We think you are entitled to know that this page is not a substitute for individual notice and that we have not resolved who is responsible for giving it, so we have said so rather than leaving the question unmentioned. If you write to us we will tell you what we hold about you and where it came from by category, and which of our customers' instructions produced it.

If you are the person a Decimio customer contacts, note that the customer is responsible for their own notice and their own lawful basis for contacting you. We require that of them in our Terms and Conditions. We cannot answer for what a customer sent you, and we can tell you whether we ever showed them your details.

California

This section is our notice to California residents under the California Consumer Privacy Act as amended by the California Privacy Rights Act. It applies to you whether or not you are a customer.

Notice at collection

We collect the following categories of personal information, for the business purposes described in this policy, and we retain each category for the periods set out in the retention section above.

• Identifiers. Name, business email address, personal email address where permitted, telephone number where permitted, professional profile URL, and our own internal identifiers.
• Professional or employment-related information. Job title, seniority, employer, and described experience.
• Commercial information. For customers, what was purchased and what was charged.
• Internet or other electronic network activity information. Limited to the IP address recorded with an access request and the ordinary server logs of our own site. We do not track you across other websites.
• Inferences. Our computed relevance score.

We do not collect sensitive personal information as the CCPA defines it, and we do not use or disclose personal information for purposes that would give rise to a right to limit its use. We do not collect biometric information, precise geolocation, or the contents of your communications.

We sell personal information; we do not share it for cross-context advertising

Under the CCPA, "sell" means disclosing personal information to a third party for monetary or other valuable consideration. Providing our customers with access to business contact data in return for payment is a sale, and we describe it as one. In the twelve months before the date of this policy we sold, and expect to continue to sell, the categories marked Identifiers and Professional or employment-related information, to the category of third party described above as our customers.

We do not sell the Inferences category. Our relevance score is calculated for one customer against criteria that customer defined, it is held in that customer's own workspace, and it is not provided to anybody else. We also do not sell the internet activity information above, which never leaves us.

We do not "share" personal information as the CCPA uses that word, which means disclosing it for cross-context behavioural advertising. We run no advertising network, we set no advertising cookie, and we do not sell to advertisers. We do not sell or share the personal information of consumers we know to be under 16.

Your California rights, and how to use them

• To know what we have collected about you, the categories of source, the business purpose, the categories of third party to whom we disclosed or sold it, and the specific pieces of information.
• To delete what we hold about you, subject to the exceptions the CCPA allows. We suppress you first, permanently and immediately, and then destroy the underlying observations, the re-checks that confirmed them and the entitlements that pointed at them. The suppression is written before anything is destroyed and outlives it, so a failure part way through leaves you protected rather than exposed. What remains is what the CCPA permits us to keep: counts, what was charged, and a one-way digest of each identifier that lets you prove an erasure happened without us keeping the identifier itself.
• To correct inaccurate personal information.
• To opt out of the sale of your personal information. Tell us and we will stop selling it, permanently and across every customer. This is the same suppression described above and it takes effect at once.
• To be free from discrimination for exercising any of these rights. We will not charge you a different price or give you a worse service because you did.

To exercise any of them, write to privacy@decimio.com with the word California in the subject line and an identifier we could know you by. We will confirm receipt within ten business days and respond within forty-five days, extending once by a further forty-five days if we need to and telling you so.

Authorised agents. You may use an authorised agent. We will ask the agent for written permission signed by you, and we may ask you to confirm directly that you gave it, unless the agent holds a power of attorney. This is to stop somebody else deleting or extracting your data in your name.

Annual disclosure. We will publish once a year, on this page, the number of requests to know, delete, correct and opt out that we received, complied with in whole or in part, and denied, and the median number of days we took. The first such figures will be published for the year in which we begin operating commercially.

California residents. We do not offer data about people who live in California. That is a deliberate limit rather than a gap, and it is wider than contact details: our software refuses the whole request for a subject in California, before any source is asked and before anything is charged. It refuses what we already hold as readily as something we would go and buy, so a value bought last week does not leave in an export this week. A customer who asks is told the request was refused, rather than quietly given a shorter list.

This is about whose data it is, not about where our customer is. A company in California is welcome to use Decimio, and will find people everywhere we cover except California itself. The limit follows the subject, so it also covers a company registered at a Californian address.

The reason is that California's data broker register applies to a business that meets one of the CCPA thresholds, and we meet none of them today. Rather than rely on being small, we have removed the activity that would bring us within the regime. If that changes we will register with the California Privacy Protection Agency and take part in the state's deletion mechanism before we lift the limit, and this section will say so.

Other United States state privacy laws

A growing number of states give their residents rights that closely resemble those above. Rather than list states and go out of date, we make this commitment: if you are resident in a United States state whose law gives you a right to confirm whether we process your personal data, to obtain a copy of it, to correct it, to delete it, to obtain it in a portable form, to opt out of its sale, of targeted advertising or of profiling with legal or similarly significant effects, or to appeal a decision we make on such a request, then we will honour that right on the same terms and within the time your state's law requires, whether or not we are strictly within the scope of that law.

Appeals. If we refuse a request, write to privacy@decimio.com with the word Appeal in the subject line. A different person will review it and answer you in writing within forty-five days with the reasons, and will tell you how to complain to your state attorney general if you are still not satisfied.

Some states, including California, Texas, Oregon and Vermont, operate registers of data brokers. Where a register applies to us, we will register and will say so here.

United Arab Emirates

If you are in the United Arab Emirates, Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data may apply to our processing of your personal data. Where it does, you have rights that correspond closely to the ones set out above: to obtain information about the processing and a copy of your data, to have it transferred to another controller where technically feasible, to have it corrected or erased, to restrict or object to processing, to object to processing for direct marketing or for automated processing that produces legal consequences, and to withdraw consent where processing rests on it. We do not rely on consent for any of the processing described above.

Exercise any of these by writing to privacy@decimio.com. We will respond within one month. Personal data about you is transferred to and processed in the United States; where the PDPL requires a basis for that transfer, we rely on the contractual safeguards recorded with our service providers and, where applicable, on the transfer being necessary for the performance of a contract or for the establishment or defence of a legal claim.

If you are within the Dubai International Financial Centre or the Abu Dhabi Global Market, a separate data protection regime applies in that free zone and we will deal with your request under it. If you are not satisfied with our answer, you may complain to the UAE Data Office or to the relevant free zone commissioner.

Children

Decimio is a business tool sold to businesses, and the data in it is about people in a professional capacity. It is not directed at children, we do not knowingly collect personal data about anyone under 16, and we do not sell or share the personal information of anyone we know to be under 16. If you believe we hold data about a child, write to privacy@decimio.com and we will suppress and investigate it.

Security

We take measures appropriate to the risk. These are the ones we can describe concretely.

• Data in transit is encrypted over HTTPS.
• There are no passwords to steal: sign-in is by a single-use emailed link that expires, and a session lives on our server so it can be revoked instantly rather than only expiring.
• The session cookie is signed, is not readable by scripts in your browser, is marked Secure in production, and is restricted to our own site.
• Every row of customer data belongs to exactly one workspace and queries are scoped to it.
• Our financial and observation records are append-only, enforced by the database rather than by convention, so they cannot be silently altered by anyone including us.
• Supplier credentials are encrypted at rest and cannot be read back, by anyone, including us: a lost key is rotated rather than recovered. The administrative console that manages them is not reachable by a customer at all.

We do not currently hold an independent security certification such as SOC 2 or ISO 27001, and we will not imply one. If a breach affecting your personal data occurs, we will notify the relevant supervisory authority and, where the risk to you requires it, you, within the periods the applicable law sets.

Changes to this policy

We will change this policy when the product changes, because a policy that stops describing the product is worse than none. The version number and date at the top always say which version you are reading. If a change materially affects your rights or the way we use your data, we will tell account holders by email before it takes effect and will describe what changed.

Complaints

Write to us first at privacy@decimio.com. We would rather fix something than be told about it by a regulator.

You can complain to a supervisory authority whether or not you have come to us first. If you are in the European Economic Area, that is the data protection authority of the country where you live, where you work, or where you think the problem happened. If you are in the United Kingdom, it is the Information Commissioner's Office. If you are in the United Arab Emirates, it is the UAE Data Office or your free zone's commissioner. If you are in California, it is the California Privacy Protection Agency or the California Attorney General. In other United States states it is generally your state attorney general.