In short
The deal data you upload is yours. You decide what it is used for. We process it for you, to build your plan and to count your dormant deals, and for nothing else.
We receive company-level deal facts only. Your browser removes every other column before it sends. A label you send can still hold a person's name: we then receive it as it is.
One person has access. No AI model reads your data.
We keep it in the EU. Two providers handle it for us. We tell you 30 days before we add one.
We delete it 30 days after your upload. You can delete it at once yourself.
If something goes wrong with your data, we tell you within 48 hours of finding out.
1. Who is who
You are the business that accepted this agreement. For the deal data you upload, you are the controller: you decide why and how it is used.
We are MN Ventures, a sole trader registered for VAT in Sweden, trading as RevivalOps. For that data we are your processor: we handle it for you, on your instructions.
This agreement is the contract that Article 28 of the EU's data protection regulation (the GDPR) asks for. For a client in the UK, it is the contract that the UK GDPR asks for.
It applies from your tick on the upload page until we have deleted your data.
It does not cover your account or our emails with you. For those we are the controller, and our privacy notice for clients says what we hold.
2. What we do with your data, and why
What it is about. Exports of your deals: one at each upload, read in your browser.
Why. These are your instructions to us, and the only purposes:
to build your plan and your moves;
to count your dormant deals, which sets your tier;
to show all of this to your team, on your plan's page and your Revival Desk;
to keep the data safe, and to delete it on time.
We do not use your data for anything of our own. We never sell it, and we never publish it.
How long. 30 days from each upload, or less if you delete it sooner.
Which data, and whose. Annex A lists every field. We ask for no data about people. Some can still come in at the edges: section 3 says how. The people it can be about are your clients and prospects who trade under their own name, and anyone whose name sits in a label.
3. The data at the edges
A sole trader's company name is a person's name. If your clients include sole traders or partnerships, their names are personal data, and we receive them.
A label can hold a name. If your CRM holds a person's name in a company field, a stage, a pipeline or a deal ID, we receive it as it is. Our page cannot tell a name from a label.
An email address does not get through. Your browser leaves out a deal whose company name holds an "@", and empties any other label that holds one. Our server refuses an upload with an "@" in any text.
Before you send, the page shows you the first 20 rows we would receive, and lets you download every row. Look through them. If a row should not go, fix it in your CRM and export again.
Do not send data about health, religion, politics, crime or children, or any other special kind of personal data. The service has no use for it.
Send your export through your private link only, never by email. If a file comes by email, we delete it unopened and send you your link.
What you write in an email to us is not part of your upload. It stays in our mailbox with the thread, as our privacy notice for clients says. So keep names from your deals out of your emails to us.
4. Your instructions
We act only on your written instructions. They are: this agreement, the terms, and what you do on our pages (you upload, you unlock, you delete).
If a law requires us to do something else with your data, we tell you first, unless that law forbids us to tell.
If we think an instruction breaks data protection law, we tell you, and we wait for your answer.
You answer for your instructions being lawful, and for your right to give us the data.
5. Who has access
One person has access to your stored data: the owner of RevivalOps. We have no staff and no contractors.
This agreement binds that person to keep it secret. Anyone who gets access later is bound to secrecy in writing first.
6. Security
We keep the measures in Annex B. They are written as they are, with what we do not have.
We may change a measure for one that protects your data at least as well.
You decide whether these measures are enough for your data. You see the measures and the data before you send anything.
7. Sub-processors
You allow us to use the providers on our sub-processor list for your data. This is a general permission in writing.
Each one is bound by a written contract with data protection duties that match this agreement. We answer to you for what they do with your data.
Before a new sub-processor starts, or one is replaced, we email the account owner at least 30 days ahead. If your firm has no account yet, we email the address we sent your private link to. The list changes on the same day.
You may object in writing within those 30 days, for a reason that concerns data protection. If we cannot solve it, you may stop: delete your data, and ask us to close your account.
If a provider fails or is breached, we may have to switch sooner. We then tell you at once, and your right to object and to leave is the same.
8. Where the data is, and transfers
We store your data in the EU: Frankfurt, Germany.
Our sub-processors are not EU companies. Their staff can reach the data from outside the EU and the UK, for example to give us support. That happens only under a transfer tool the law accepts: an adequacy decision, such as the EU–US Data Privacy Framework with its UK Extension where the provider is on its list, or else the EU's standard contractual clauses with the UK addendum. The sub-processor list names the tool for each provider.
We make no other transfer of your data out of the EU and the UK without telling you first.
If you are in the UK, Annex C applies. If you are outside the EU and the UK, Annex D applies. If you are in the US, Annex E applies too.
9. Requests from people
We hold no columns about people, so we can seldom find a person in your data.
If a person writes to us about data in your upload, we pass the request to you within 5 working days. We do not answer it ourselves, beyond telling the person that we passed it on.
If you ask, we help you answer a request. We do not search your stored rows: our fixed code alone reads them, and nobody opens them. To remove a name from what we hold, delete your data (section 12.2), correct the record in your CRM, and send a new export on a new link, which we send you when you ask. To correct a row, do the same.
You can delete everything yourself at any time (section 12).
10. Help with your own duties
If you ask, we give you the facts we have for your own duties under Articles 32 to 36 of the GDPR: your security, a breach notice, an impact assessment, or a talk with your regulator.
We help as far as our part of the processing goes, and from what we hold.
11. If something goes wrong
A breach is any event where your data is lost, changed, shown to or reached by someone who should not have it.
We tell you without undue delay, and within 48 hours of finding out. We write to the account owner's address, or to the address we sent your private link to.
We tell you what happened, which uploads and about how many rows, what we have done, and whom to ask. We send more as we learn it.
We keep a log of every breach.
Telling your regulator, or the people in the data, is your decision as the controller. We help you with the facts.
12. Deletion and return
After 30 days. We delete each upload 30 days after you sent it. A job runs every hour and deletes each upload whose 30 days are up.
At once. You can delete every upload yourself: "Delete my data now" on your plan's page, or "Delete everything now" on your account page. Or write to privacy@revivalops.com: we delete within 2 working days and confirm by email.
Your copy. We hold a copy only: your data stays in your CRM. Before you send, the page lets you download exactly what we receive. Keep that file: it is your copy. We make no other file of what we hold, because nobody opens your stored rows.
Backups. Our database provider keeps daily backups for 7 days. A deleted upload is gone from the backups within 7 days after that.
What stays. Two records stay after deletion, as proof of what we did. Neither holds a deal, a company or a person:
the record of your tick: which version of the papers, the fingerprint of the text you saw, and the time;
the log: each upload, unlock and deletion, as a fixed word, a time and a count of rows.
The deletion and retention sheet says how long each one stays, with everything else we keep as the controller, such as your team's sign-ins.
Your account page shows the log, with a line for each deletion. If your firm has no account yet, ask us and we send you its lines.
13. Checks
Once a year, and after any breach, you may send us written questions about how we keep this agreement. We answer within 30 days.
We give you our providers' own audit reports, or their summaries, as far as the providers allow.
You, or an independent auditor you choose, may also check us: once a year, and after any breach. You give 30 days' notice and carry your own cost. The auditor is bound to secrecy, and sees no other client's data.
We have no office. A check is done from a distance: our settings, our logs and our papers, shown on screen or sent as files.
14. AI
No AI model reads your data. Fixed rules build your plan. This holds for our own work too: we do not give your stored rows, or a link to your plan, to an AI tool.
We will not change that for your data unless you agree in writing first. An AI provider would then be a sub-processor: named on our list, bound by contract, and barred from training on your data.
15. Liability
The limits in the terms apply to this agreement too, as far as the law allows.
They never limit what a person can claim for themselves under data protection law, or what a regulator can do.
16. Changes to this agreement
We may change this agreement when the law, a provider or our security changes. We email the account owner at least 30 days before a change starts. If your firm has no account yet, we email the address we sent your private link to.
Every upload page shows the version in force. You accept that version when you tick the box. We store the version, the fingerprint of the text and the time.
If you do not accept a change, you can delete your data before it starts, as the terms say.
17. Law
Swedish law governs this agreement, and Swedish courts decide, as in the terms.
On anything about personal data, this agreement comes before the terms.
Annex A: the data, field by field
Your browser reads your export on your own computer. It keeps the fields below and drops every other column, unread. Our server refuses an upload that holds any other field.
| Field | What it is | Why we need it |
|---|---|---|
| Deal ID | Your CRM's own id for the deal. If the export has none, the page makes one from the company, the created date and the value. Never the deal's name | To match a deal across two uploads. That is how we count results |
| Company | The company's name, as your CRM has it | Every move is for a company |
| Stage | The stage's label, as your CRM names it | Where the deal stopped |
| Status | Open, won or lost | To sort lost deals, quiet deals and past clients |
| Value and currency | The deal's money, and its currency code | The money in your plan, and the order |
| Created date | The day the deal was made | The deal's age |
| Closed date | The day it was won or lost | How long ago |
| Last activity date | The last day someone worked the deal | How long it has been quiet |
| Next activity date | A day something is booked, if any | A company with something booked gets no move |
| The kind of lost reason | One of a fixed list: asked not to be contacted; out of business; a duplicate, test or spam record; not a fit; a competitor; budget timing; price; no answer; timing; no decision; no reason given; a reason we can't read. Your browser reads the reason and sends only its kind, never its words | The angle of the move, and which companies to leave out |
| Pipeline | The pipeline's label, as your CRM names it | To keep your lines of business apart |
| Do not contact | Yes or no. Read from a do-not-contact or opt-out column, if the export has one. Never whose it is | A marked company gets no move |
With each upload we also store: the day and time, the CRM the export came from (guessed from its column names), and the number of rows. For our own note that a plan is ready, we store three counts (deals, moves and dormant deals) and the tier. We also hold your firm's name, and the average deal size and currency you gave us by email, if you gave them: we use them for deals that have no value.
What your browser drops, before anything is sent:
people: contact names, first and last names, email addresses, phone numbers, job titles, the deal owner, and any "associated contact" column;
free text: notes, descriptions, comments, next steps, and the words of a lost reason;
deal names;
rows whose newest date is more than 36 months old;
a deal with no company, and a deal whose company name holds an "@";
every other column.
We never receive the file itself. Only the fields above leave your computer.
Annex B: security, as it is
In your browser
The file is read on your computer. Only the fields in Annex A are sent.
The page shows the first 20 rows, and lets you download every row, before you send. Nothing is sent before you tick the box and press Send.
On the way, and on our server
Everything travels over HTTPS.
Our server checks the same list of fields again. It refuses the whole upload if it finds another field, a value of the wrong kind, or an "@" in a text. The database checks a third time.
The raw file is never stored. The plan is not stored either: it is built again from the stored facts each time you open it, so deleting the facts deletes the plan.
In the database
Every row carries your firm's id. A rule on every table lets a signed-in member read only their own firm's rows. A check lists any table that lacks the rule, and our own changes to the database stop while it lists one. A test with two made-up firms tries to read and write across the line. Every attempt has to be refused.
A private link holds a long random token, signed with a key that is made inside the database. An upload link works for one upload, and for a set time: 14 days as a rule, never more than 60. A plan link works for 30 days at most, and ends sooner if its data is deleted. We can end a link at once.
A link is not enough by itself: each call also needs a second key that only our server holds. Each link has a budget of requests a minute.
The move of a locked company never leaves our server.
The stored data is encrypted at rest by our database provider.
Sign-in
Your team signs in with a link sent to their email address. There are no passwords. The sign-in cookie cannot be read by scripts on the page.
Our own access
One person has access. That person signs in to our database, our host, our code and our payment provider with two-factor sign-in.
Keys are kept out of the code. The server that runs the app does not hold the database's master key.
Logs and messages
The log holds fixed words, roles, random ids and counts. It holds no deal, no company and no person.
Our host logs each request: the IP address, the time and the page's address. A private link is such an address, so the host's logs hold it. Only we and the host can read those logs.
Our emails to you, and our own alerts about your plan, carry links and counts. They carry nothing else: no money, no company's name, no deal's value.
Backups
Our database provider makes daily backups and keeps them for 7 days.
What we do not have
We are a one-person firm. We hold no SOC 2 or ISO 27001 certificate of our own. Our providers hold their own.
No outside firm has run a penetration test on the service yet.
Annex C: clients in the UK
For a client in the UK, "the GDPR" in this agreement also means the UK GDPR and the Data Protection Act 2018.
Your data comes to us in the EU: we are in Sweden, and we store it in Germany. UK law treats the EU as giving adequate protection, so no extra clauses are needed for that step.
We show you your plan in the UK. The EU treats the UK as giving adequate protection, so no extra clauses are needed for that step either.
Where a sub-processor reaches data from outside the UK, section 8.2 applies, with the UK addendum or the UK Extension.
Your regulator is the UK's Information Commission. Ours is the Swedish Authority for Privacy Protection (IMY).
Annex D: clients outside the EU and the UK
EU data protection law binds us as your processor, whatever your country.
We show you your plan. Where EU law treats that as a transfer to you that needs a transfer tool, the EU's standard contractual clauses apply between us, in the version of Commission Decision (EU) 2021/914, module four (processor to controller). They are then part of this agreement.
For those clauses: we are the data exporter and you are the data importer. The data and the purposes are those of section 2 and Annex A. The transfer happens each time you open your plan. Swedish law governs the clauses, and Swedish courts decide.
If the clauses and this agreement disagree, the clauses come first.
Annex E: clients in the US
This annex applies if a US state privacy law covers the data you upload, such as California's Consumer Privacy Act (the CCPA).
We are your service provider, or your processor, as that law names it.
We process your data only for the business purposes in section 2.2.
We do not sell your data, and we do not share it for advertising.
We do not keep, use or disclose your data for any other purpose, or outside our direct relationship with you.
We do not combine your data with data from another client or another source.
We follow the parts of that law that bind a service provider, and we protect your data as that law requires.
If we can no longer meet these duties, we tell you within 5 working days.
You may take reasonable steps to check that we use your data as this annex says, and to stop and fix any use that breaks it. Section 13 says how you check.
If a person sends us a request under that law about your data, we pass it to you, as in section 9.
Our sub-processors are bound to the same duties.