Privacy Policy

Steek is operated by Morrive LLC, a limited liability company formed in Florida, United States, with its registered office at 7901 4th St N, Ste 300, St. Petersburg, FL 33702, USA. For your own account, Morrive LLC is the controller: it decides what is collected and why. You can reach us about anything in this policy, and about any of the rights in section 10, at legal@steek.io.

Where we answer to. Morrive LLC is run from Romania, so for European data protection purposes we are established in the European Union and our lead supervisory authority is the Romanian National Supervisory Authority for Personal Data Processing (ANSPDCP). That does not narrow your options: section 10 explains that you may complain to the authority where you live or work, whichever is easiest for you.

We have not appointed a Data Protection Officer, and we would rather say so than leave you guessing. The law requires one for public authorities, for large-scale monitoring, and for large-scale processing of special-category data. None of those describe us — Steek cannot read the documents it carries. legal@steek.io reaches the people actually responsible, and we will appoint one and name them here if that ever changes.

A note on roles. When a business customer uses Steek to send documents to their clients or staff, that business is the controller of that content and we act on their behalf.

This policy covers three groups of people, and the third is the one usually left out. We mean it literally: if a sender typed your address into Steek, we hold personal data about you even though you have never visited us, never registered, and never agreed to anything. You did not give us that address, the sender did. We keep it, and we show it to the sender and their organization. Section 2.5 says what we hold, section 3 says why we are allowed to, and section 10 says how to object. None of that depends on you having an account.

• People with accounts: senders, recipients, organization members and administrators.
• People without accounts who open a document through a link or a QR code.
• People whose email address someone else entered as a recipient, even if they never open anything.

This is what you hand us yourself, by using Steek.

• Your account: email address, name (optional), the password-free credentials (passkeys) you register, and the labels you give your devices.
• Your settings: notification preferences, language, theme, and security preferences such as how long a document stays unlocked in an open tab.
• What you send: the encrypted document, its title, its original filename, and the size of the encrypted file. The title and the filename are stored unencrypted. See section 4.
• Who you send it to: the email address you typed, stored in the clear on the delivery record, alongside the recipient's account if they have one. We also keep a one-way hash of it, which is what the system matches on. The address is kept whether or not the recipient ever registers, and it is shown back to you and to your organization. See sections 5.2 and 8.3.
• One historical exception: grants made before we started storing the address carry only the irreversible hash. Those cannot be un-hashed and stay masked permanently. Where the product cannot show you an address, it says which of the two reasons applies.
• Billing details: your billing address and, for business purchases, a VAT or tax number.
• What you write to us: support messages, feedback and appeals.

We do not collect location data. There is no geolocation anywhere in Steek: no country, no city, no coordinates, and no service that turns a network address into a place. We record the address your connection came from; we never look up where that is. We also do not fingerprint your device beyond the user-agent string described below.

Two different rules apply, on purpose. Your own sign-ins record your network address in the clear, because that is the only way a security log is useful to you: 'someone signed into your account from an address you have never used' is not something a hash can tell you plainly. Anyone opening a link you shared is recorded only as a one-way hash. We can tell that two opens came from the same place, and we cannot read out where that place was. Sharing a document with someone does not let us, or you, learn their network address.

Who can see your sign-in log. You can, always. If you are a member of an organization, its administrators and security officers can see it too. Read section 5.2, because your sign-in history is account-wide and is not limited to the times you were working with that organization.

This is what the service records as it runs.

• Sign-in sessions. For each sign-in we record the time, the passkey device used, how you signed in, your network (IP) address and your browser's user-agent string, and how the session ended. You can see all of it yourself under your account, as described in section 10. It is deleted 90 days after the session expires.
• Document activity. When a document is opened or downloaded: which document, which access, how it was opened, which device and session, and the count and time of downloads.
• Link and QR opens. When someone opens a share link we additionally record a hash of their network address, a hash of their user-agent, which link was used, and whether it was a QR scan or a copied link.
• Audit events. A structured record of significant actions: sign-ins, key changes, sharing, revocation, administrative actions, blocking.

We have checked this against our own code, and we state it plainly. The only cookie we set is the one that keeps you signed in, described in section 9.

• No analytics. No Google Analytics, no product analytics, no session recording, no heatmaps.
• No advertising and no tracking cookies. None.
• No third-party trackers or pixels.
• No error-reporting service that would receive your data.
• No SMS or phone number collection.
• No location data.

If you choose to verify your identity or your business, that check is run by a specialist provider through our identity service.

Verification is optional. You can use Steek without it, at a lower trust level.

• Personal identity: your government ID and a selfie go directly from your browser to the verification provider. They do not pass through our servers. We receive only the outcome.
• Business verification: the business's legal name, tax identification number, address, website and the names of associated people are sent to a business-verification provider.

This section is for the person who never signed up. Everything else in this policy is written to people with accounts; this part is not.

How we got your address. You did not give it to us. A sender typed it in, in order to send you something. That is the only source. We did not buy it, look it up, or collect it from anywhere else.

Who sees it, and we will say this plainly: the sender does. We show your address to the person who sent you the document, and to the administrators of the organization they sent it for. It is shown as readable text, next to that document, for as long as they keep it. That is deliberate. A sender who cannot see who holds their confidential document cannot check they sent it to the right person, and cannot take the access away. Nobody else sees it: not other users, not other organizations, not the public, and not advertisers. Section 5.2 has the full list.

How long. For as long as the sender's record of that delivery exists. That record belongs to the sender. It is their proof that they sent something to you, so it does not end when your involvement does. If you later open an account at that address and then delete it, the sender's record still shows the address, as section 8.3 explains.

Why we are allowed to. Legitimate interests, not consent. You never gave consent and we are not going to pretend you did. Section 3 sets out the interest, weighs it against your rights, and says how to object.

What you can do. Every right in section 10 is yours, and none of them needs an account. Ask us what we hold about your address. Ask us to correct it. Object to us holding it at all, and we will answer you properly rather than quoting the rule back at you.

One thing we will not do is pretend. An objection does not delete the sender's record of a delivery that happened. We can stop emailing you, and we will if you ask. We cannot rewrite one person's record of what they sent to make it say they sent it to nobody. If we ever refuse an objection we will tell you we refused it and why, so you can complain to a regulator. Section 10 explains how.

What we do not hold. No profile, no name unless a sender wrote one, no location, no tracking across sites, no marketing list. We never email you anything except the notification about the document you were sent. Your address is not used for anything else and is never sold or shared for advertising. In full, what we do hold about you is this:

• The email address the sender typed, in the clear, on the record of that delivery, plus a one-way hash of it used for matching.
• The fact that a specific document was addressed to that address, and when.
• If you open it: the time, whether it was a link or a QR code, and a hash of your network address and browser. Never the address itself in readable form, as section 2.2 explains.

We do not rely on consent for the core service. That is deliberate. If we relied on consent, you could withdraw it and we would have to stop delivering your documents. Contract and legitimate interests are the honest bases, and they are also the ones that let us keep the security and audit records that protect everybody.

Where we rely on legitimate interests, you can object. Section 10 says how. This is what we process, why, and on what basis.

• Account, credentials and settings, to give you the service you asked for. Basis: performance of a contract.
• Encrypted documents and delivery, to deliver documents to your recipients. Basis: performance of a contract.
• A recipient's address where the recipient has an account, to address and control access and to show the sender who holds the document. Basis: performance of a contract, with the sender to deliver, and with the recipient, whose own account terms cover it.
• A recipient's address where the recipient has no account. Same purpose, but this person agreed to nothing, so contract cannot be the basis. Basis: legitimate interests, being the sender's need to know and evidence who they delivered a confidential document to. Section 3.1 sets out the balancing test.
• A recipient's address kept after that person erases their account, so the sender keeps a complete record of a delivery that actually happened and can evidence it. Basis: legitimate interests, and the establishment, exercise or defense of legal claims. See section 8.3.
• Sender identity recorded on the recipient's copy, so a recipient can prove who sent them a confidential document. Basis: legitimate interests, being the recipient's need for reliable provenance and ours in a trustworthy service. See section 8.3.
• Sign-in records (network address, browser, device, timestamps) and access records (hashed address for link opens), for security, fraud and abuse investigation, and as evidence that a document was delivered and opened. Basis: legitimate interests.
• Audit logs, for accountability, security, and proof the service ran correctly. Basis: legitimate interests, and legal obligation where retention is required.
• Abuse reports and attached evidence, to investigate abuse and protect users. Basis: legitimate interests.
• Billing records and invoices, to take payment and to keep the records tax law requires. Basis: performance of a contract, and legal obligation.
• Terms-acceptance record, to evidence the contract between us. Basis: performance of a contract, and legitimate interests.
• Electronic signature evidence, to produce reliable proof of signature for every signatory. Basis: performance of a contract, and the legitimate interests of the other signatories.
• Identity verification, to establish trust level where you ask for it. Basis: consent, and performance of a contract.
• Service emails, to tell you about your documents, your account and your security. Basis: performance of a contract, and legitimate interests.

Two different people are named on every delivery, and only one of them ever agreed to anything. We set this out separately rather than hiding it in a table row, because it is the one place where we process data about somebody who is not our customer.

The interest we are pursuing. A sender needs to know who they sent a document to. Not a hash. Not 'a recipient'. The actual address. Without it, a sender cannot check they addressed it correctly, cannot decide whose access to remove, cannot tell their own auditor where a confidential file went, and cannot prove they delivered it if someone later says they did not.

It is the same interest, pointing the other way, that makes us keep the sender's identity on the recipient's copy. We do not think a document delivery service can be run where either end is a mystery to the other.

Why it does not override your rights, if you are that recipient. Nothing new is disclosed: the address is shown to the person who already had it, because they typed it to reach you. We are not introducing you to anyone, building a profile, or widening the audience beyond the sender and the organization they sent on behalf of.

It is the minimum. One address, on one delivery record. No name we invented, no enrichment, no location, no behavioral data.

You would expect it. Someone who emails you a document knows your address afterwards. A courier keeps the delivery address. It is difficult to describe a document-delivery service in which the sender is not told who they delivered to.

It is not used against you. No marketing, no sale, no sharing for advertising, no cross-context tracking, and no notification to you other than the one about the document itself.

And where it does not go our way. Object under section 10 and we will look at your actual situation instead of repeating the paragraphs above. Ask us to stop emailing you and we will. What we cannot do is delete the sender's record of a delivery that really happened. That record is theirs, not ours to erase, and saying otherwise would be a promise we could not keep.

How we tell you this at the time. You will not have read this policy before your address was recorded; nobody does. The one message we ever send you is the notification about the document itself, and it carries a link to these terms. That notification is the only place we can reach you, so it is where we tell you.

Two automatic rules operate without a human: a share link opened from more than five different places within an hour is revoked, and a document reported by enough of its recipients is blocked, which can lead to an account suspension.

These are fixed published rules applied to events. They are not profiling, and they are not an assessment of you as a person. Every one of them can be reviewed and reversed by a person. Ask us, as described in section 10 and in section 7.5 of the Terms and Conditions.

Most services are vague here. We will not be. Because of the items below there are requests we cannot satisfy, from you, from your employer, or from a government. We cannot produce plaintext we do not have.

• The contents of your documents. Encryption and decryption happen in your browser. No part of our service decrypts them. There is no endpoint, no admin tool and no support process that can.
• The keys. File keys, your account private keys, your device keys and your recovery private key never leave your devices in a form we can use.
• The contents of bundle conversations. We store unreadable ciphertext.
• The real file type. The content type we store is a fixed wrapper label. The real type of your file is inside the encrypted package.

Anyone holding a valid share link can also see the title and the filename before opening the document.

Practical advice: treat the filename and the title as public to us and to anyone with the link. Put nothing confidential in either. In full, this is what is visible to us.

• The document's title, stored unencrypted.
• The original filename, stored unencrypted.
• The size of the encrypted file, and every timestamp.
• Who sent it, and the email address it was sent to, in the clear, whether or not that person has an account. See section 2.1.
• The organization and subdomain involved.
• Every open and download, and the delivery receipts.
• Notification content, which includes the document title.

We cannot read bundle conversations. So when someone reports a message for abuse, they attach a decrypted excerpt themselves. The reporter is told before submitting that moderators will see it.

That excerpt is the only readable message content we ever hold. We keep it as abuse evidence, and our administrators can read it for moderation. It is not returned in a data export, and it is not removed by an erasure request, because it is evidence about conduct rather than a record we hold on the reporter's behalf.

Our servers can encrypt, never decrypt, for the small number of documents Steek itself authors and sends you, such as an integrity report. Those are sealed to your public key, which means we produce a package we ourselves cannot open. This never applies to a document a user uploads.

We do not sell your personal data. We never have. We do not share it for advertising, and we do not allow anyone we work with to use it for their own purposes.

These are the providers that process data on our behalf, and what each one receives.

• Stripe, for payments and subscriptions: your email address, billing address, and plan details. Your card details go directly to Stripe and never reach us.
• Stripe Identity, for optional personal identity verification: your government ID and selfie, sent directly from your browser. We pass only an anonymous reference.
• Middesk, for optional business verification: business legal name, tax ID, address, website, and associated people's names.
• Mailgun, for sending service email: recipient email address, and the subject and body of the notification. Never document content.
• Cloudflare R2, for encrypted file storage, archived audit logs and database backups: encrypted document files, unreadable to the provider and to us.
• Mitome, our own identity service: email, name, verification standing and trust level.

Your recipients see your name, email, organization and trust level, permanently. Section 8.3 explains why.

Your senders see the address they sent to, permanently, and after you erase your account. Section 8.3 explains why. If you were sent something at an address you no longer use, the sender's record still shows that address.

Organization administrators see the addresses documents were sent to from their organization, and the addresses that sent documents to it. This is how an organization knows where its documents went and where they came from. It is not limited to the member who did the sending.

Our administrators, when reviewing a request for a private subdomain, see the email address of the person who requested it, so a human can judge who is asking before a subdomain is created.

Your organization's administrators see your organization activity, membership and billing. They do not see your personal document activity.

Our administrators can see account records, audit events, abuse reports and reporter identities where moderation requires it. They cannot see document contents.

Your organization's administrators and security officers also see your sign-in log. This one needs saying in full, because it is broader than it sounds. A sign-in belongs to your account, not to one organization, and Steek has no way to tell which of your organizations you had in mind when you signed in. So what an administrator of any organization you belong to can see is your whole sign-in history within the 90-day window: the times you signed in, the passkey device, your network address, your browser, and how each session ended. That includes sign-ins on days you did nothing for that organization.

• Only administrators and security officers can see it. Ordinary members and auditors cannot.
• It stops when you leave. Once your membership is removed, that organization's administrators can no longer see your sign-ins, including the ones from while you were a member.
• It is the same history you can see under section 10, never more.
• If you would rather an organization not have this visibility, the answer is not to join it with an account you also use personally.

We will disclose data where we are legally required to, or where it is necessary to investigate abuse, protect users, or enforce our Terms.

What we can hand over: account records, metadata, filenames, titles, timestamps, sign-in records including network addresses, hashed addresses for link opens, audit and access logs, and billing records.

What we cannot hand over: the contents of your documents or your conversations. We do not hold them in a readable form and we cannot produce them.

Where the law allows it, we will tell you about a request before responding.

If Steek is merged, acquired or sold, data may transfer to the buyer, who remains bound by this policy or gives notice of a change. Encrypted content stays encrypted, and a buyer gains no ability to read it.

Some of the providers in section 5.1 operate outside the EEA and the UK, so some of your data is processed outside those territories.

This version of the policy does not state the hosting country of each system, or the specific safeguard applied to each of those transfers. Those details will be published in this section. Until they are, ask us at legal@steek.io and we will tell you.

One honest note before the list: some entries say 'indefinitely' because that is what the system does, not because we chose an elegant number.

Why some share links are kept longer. A share link that was used or revoked is genuinely finished, so it goes. Two kinds stay: a link that simply expired unused, because 'this access lapsed' is an entry in the document's activity history that the owner can see; and a link that backs a reusable share campaign, because deleting it would take the campaign and its history with it.

Legal hold. We can freeze deletion for specific data where litigation, an investigation or a legal obligation requires it. A hold overrides every retention rule below, including the purge of signed documents. These are the periods.

• Your account: until you delete it, and then anonymized rather than removed. Section 8.2 explains what that means.
• Encrypted documents: until deleted by their owner, or by the limits in the Terms. Deletion destroys the keys too, so it is permanent.
• Documents after an account or organization ends: 30 days, then deleted. Download what you need in that window.
• Documents that have been signed: the file is purged only once every holder has removed their own copy. The signing evidence is kept permanently.
• In-app notifications: 30 days.
• Uploads that never completed: 7 days.
• Audit logs on the main platform: kept live for 3 months, then moved to long-term archive storage. Archived, not deleted.
• Document-related audit events: kept indefinitely. Never deleted from either the live table or the archive.
• Audit logs on private subdomains: kept indefinitely, backed up monthly.
• Sign-in session records: 90 days after the session expires. This includes the network address and browser of that sign-in, as described in section 2.2. If you erase your account they are deleted immediately, not after 90 days.
• Sign-in verification challenges and emailed codes: 7 days after they expire. They are refused the moment they expire; the week is operational slack.
• Share links, once used or revoked: 90 days after they expire.
• Share links that expired unused, or that back a share campaign: kept while the document exists.
• Abuse reports and attached evidence: kept indefinitely as evidence. They survive deletion of the document and of both accounts.
• Electronic signature evidence: kept indefinitely. That is the point of signing, as section 9 of the Terms explains.
• Invoices and payment records: as long as tax and accounting law requires.
• Terms-acceptance record: kept for as long as we may need to evidence the contract.
• Sender identity on a sent document: permanently. Read section 8.3.
• A recipient's email address on a delivery record: as long as the sender keeps that record. Section 8.3 explains that this survives the recipient's own account erasure, and applies to recipients who never had an account.
• Database backups: 5 days.

This is the section people most need to read, and it is the one usually buried. It is not buried here.

Delete your account from your settings and confirm with your passkey. You cannot delete while your account is blocked, while you are the sole administrator of a live organization, or while your account is homed on a private subdomain.

Deletion is real, and most of it is irreversible. This is exactly what happens.

• Your email address is replaced with a non-routable placeholder on your account record, and your name is removed. It is not removed from the delivery records of documents other people sent you, or from documents you sent. Section 8.3 explains this.
• The keys are destroyed. Your account keys, device key envelopes and recovery wraps are deleted outright. Anything encrypted solely to you becomes permanently unreadable, including by us. This is real cryptographic erasure, not a flag in a database.
• The mapping from your email address to your identity is deleted.
• Your connections are deleted.
• Your access to documents other people sent you is revoked.
• Documents you own personally are deleted after 30 days, and their keys destroyed.
• You cannot re-register the same email address for 30 days.

The one that matters: your recipients keep your identity, permanently.

When you send a document, we record your name, your email address, your organization's name, its verification status, the subdomain you sent from, and your verified trust level onto that document, at that moment, permanently.

The recipient keeps seeing that record. They keep seeing it after you delete your account, after your organization is deleted, and after your subdomain is torn down. It is captured once and never changes. There is no setting that turns it off and no request that removes it.

Why. A recipient of a confidential document must be able to prove who sent it. If a sender could erase themselves from the recipient's copy, then every document could later be disowned, and the recipient would be left holding something they could not attribute. Their interest in reliable provenance, and everyone's interest in a service where a sender cannot repudiate what they sent, outweighs a sender's interest in being forgotten by the specific person they chose to contact.

In plain terms: sending someone a document permanently discloses your name, email and organization to that person. You cannot take it back. Deleting your account does not take it back. If you are not willing for the recipient to hold that record permanently, do not send them a document. We tell you this here rather than in a support article, because the only moment you can act on it is before you send.

The other one: the people who sent you documents keep your address. The same rule, pointing the other way, and it catches people out more often, because it applies even if you never sent anything.

When somebody sends you a document, the address they sent it to is written onto their record of that delivery. Deleting your account does not remove it. Your account record is anonymized; their delivery record is not. The sender, and the administrators of the organization they sent for, keep seeing the address they sent to.

Why. It is their record of something they did, not a record we keep about you on your behalf. A sender has to be able to say where a confidential document went, to check it, to withdraw access, to answer their own auditor, or to prove delivery in a dispute. If deleting an account rewrote every sender's history so their documents appeared to have gone nowhere, we would be destroying other people's evidence to tidy up yours.

This applies whether or not you ever had an account. If a sender typed your address and you never signed up, there is no account to delete and the record still exists. Section 2.5 is written for you.

In plain terms: being sent a document at your address permanently tells the sender that they sent it to that address. Deleting your account does not take that back. There is no setting that turns it off.

What deleting your account does still achieve: your account, name, keys, connections and access are gone; anything encrypted only to you becomes permanently unreadable; and nobody can reach you at that address through Steek again. What it does not achieve is editing other people's records of what they sent you. The rest of what survives, and why, is this.

• Audit and security logs, including a record that your account was erased and the address it had. Why: evidence the service was operated correctly, and that the erasure happened.
• Your terms-acceptance record, meaning the version and the time. Why: evidence that a contract existed.
• Electronic signature evidence: receipts, envelopes, consent records. Why: the other signatories' proof cannot be destroyed by one party leaving.
• Invoices and payment records. Why: tax and accounting law.
• Abuse reports about your documents, and attached evidence. Why: evidence of conduct. Erasing it would let abuse be cleared by deleting an account.
• Access you granted to others. Why: so their access is not silently broken.
• Documents you sent, held by their recipients. Why: they are the recipient's copy, with your identity on it, as above.

We set one cookie: the one that keeps you signed in. It is restricted to our own site, cannot be read by scripts, is sent only over an encrypted connection in production, and lasts 7 days.

We set no analytics cookie, no advertising cookie, and no tracking cookie. There is no consent banner because there is nothing to consent to.

Your browser also holds working data while you use Steek: decrypted material for documents you have open, and your interface preferences. Decrypted material stays in memory only. It is never written to disk and never sent to us. It is cleared when the tab is hidden or closed, after a short period of inactivity, and when your chosen unlock window expires.

Wherever you live, we will honor these. Under GDPR and UK GDPR they are legal rights.

How to use them. Email legal@steek.io, or use the settings in the product. We will respond within one month, extendable by two further months for complex requests, and we will tell you if we extend. We do not charge, unless a request is manifestly unfounded or excessive.

We may need to verify your identity, usually by asking you to act from your account with your passkey. Your rights are these.

• Access: get a copy of what we hold about you.
• Portability: get it in a machine-readable form, as described in section 11.
• Rectification: correct what is wrong. Note that a sender identity record already written to a recipient's copy is a historical record of a past event and is not corrected retrospectively.
• Erasure: delete your account, subject to section 8.3.
• Restriction: ask us to stop processing while a dispute is resolved.
• Objection: object to anything we do on the basis of legitimate interests, including the security telemetry in section 2.2. We will stop unless we have compelling grounds that override your interests, and we will explain which.
• Withdraw consent, where we rely on consent, such as identity verification.
• Human review: ask a person to review any automatic block, revocation or suspension.
• Complain to a data protection supervisory authority: the one where you live, where you work, or where you think the problem happened.

Export your data from your settings; you will confirm with your passkey. You can do this up to 5 times an hour, and you can do it while your account is blocked.

The export includes your account details, your settings, your connections, your most recent 500 audit actions, and the sender-identity records for your 500 most recent sent documents, so you can see exactly what your recipients see about you.

The export does not include your document contents. Your documents remain listable and downloadable individually through the app for as long as you hold them, and that is how you retrieve them today.

We protect your data with encryption in transit and at rest, encryption on your device before upload, password-free authentication with re-verification for sensitive actions, strict browser security policy, rate limiting, abuse detection, audit logging, and network-edge protection.

Our encryption is designed to resist future quantum attack: every asymmetric operation uses a classical algorithm and a post-quantum algorithm together, so breaking one is not enough. Every encrypted object records which algorithms produced it, so we can adopt new ones without losing access to old documents.

We cannot guarantee perfect security. No one can.

If there is a breach affecting your personal data, we will investigate, contain it, and notify the relevant supervisory authority within 72 hours where the law requires, and notify you directly without undue delay where the risk to you is high.

Steek is not for children. We do not knowingly collect data from children. If we learn that we have, we delete it. If you believe a child has given us data, contact us.

We will update this policy as the service changes. Material changes are notified in the product, and continued use after they take effect means you accept them. Minor changes are published without a prompt. Every version is kept so you can see what changed.