On this page16 sections
- 1Who this policy is for
- 2Who is responsible for your personal data
- 3What we collect, why, and on what legal basis
- 4Sensitive and special category data
- 5Children
- 6Who we share personal data with
- 7Requests from law enforcement and government
- 8Where your data goes
- 9How long we keep things
- 10How we protect it
- 11Your rights
- 12How to exercise a right
- 13If there is a data breach
- 14Automated decisions and profiling
- 15Who to contact
- 16Changes to this policy
Genflix Commerce Private Limited, a private limited company, operating as DropTheDoc ("we", "us"), provides an electronic signature service at suresign.si. This policy explains what we do with personal data. It is written to satisfy the notice requirements of the Digital Personal Data Protection Act, 2023 (India), Articles 13 and 14 of the UK and EU General Data Protection Regulation, and the notice-at-collection requirement of the California Consumer Privacy Act.
The short version
We collect what we need to deliver your documents, prove who signed them, keep your account secure and bill you. When you use the agent, the content a request needs is processed by our AI provider, Anthropic, which may not train on it. We do not sell personal data, we do not share it for advertising, we run no advertising or analytics trackers, and we do not use the contents of your documents to train any model. The audit trail is the one thing we cannot delete on request, because it is the evidence that makes a signature hold up.
1.Who this policy is for
This policy covers three groups of people, who are in different positions and should read different parts of it:
- Account holders.
- You created a DropTheDoc account and send documents. Everything here applies to you.
- Recipients and signers.
- Someone sent you a document, or you asked for one through an open link. You may not have an account and you do not need one. Clause 2 explains who is responsible for your data, and clause 12 explains how to exercise your rights.
- Visitors.
- You are reading our website. We collect very little from you. See the cookie policy.
2.Who is responsible for your personal data
This is the most important clause in the policy, because it determines who you go to about what.
Data
Account and billing data of account holders
Our role
Data Fiduciary under the DPDP Act; controller under GDPR
What it means for you
We decide why and how this is processed. Bring requests about it to us.
Data
Documents, fields and the personal data inside them
Our role
Data Processor under the DPDP Act; processor under GDPR
What it means for you
The account holder who uploaded the document decides what it contains and how long to keep it. We act on their instructions. Bring access and deletion requests to them, and we will support them in answering you.
Data
Recipient names and email addresses supplied by a sender
Our role
Processor, on behalf of the sender
What it means for you
The sender chose to send you a document. If you did not expect it, contact them. We will pass on a request if you cannot reach them.
Data
The audit trail and evidence records
Our role
Independent controller
What it means for you
We keep this to meet our own legal and evidentiary obligations. Neither you nor the sender can instruct us to alter or selectively delete it, because a log that can be edited on request is not evidence.
Data
Conversations with the agent, the drafts, answers and actions it prepares, and the facts it keeps in memory
Our role
Data Processor under the DPDP Act; processor under GDPR
What it means for you
The agent works on your workspace's content at the request of the people in it. A conversation is visible only to the person who had it. The facts it keeps for the workspace are visible to everyone in it, and the ones it keeps for one person only to that person. What the agent does to a document is also written to that document's audit trail.
Data
The public record of completed documents
Our role
Independent controller
What it means for you
We publish each completed document's hash, reference code and completion time, so anyone can check a signed file against it. It holds no names, addresses or content, and entries are never removed.
Data
Security, fraud prevention, abuse and rate limiting
Our role
Independent controller
What it means for you
We process this to keep the service safe for everyone, on our own responsibility.
| Data | Our role | What it means for you |
|---|---|---|
| Account and billing data of account holders | Data Fiduciary under the DPDP Act; controller under GDPR | We decide why and how this is processed. Bring requests about it to us. |
| Documents, fields and the personal data inside them | Data Processor under the DPDP Act; processor under GDPR | The account holder who uploaded the document decides what it contains and how long to keep it. We act on their instructions. Bring access and deletion requests to them, and we will support them in answering you. |
| Recipient names and email addresses supplied by a sender | Processor, on behalf of the sender | The sender chose to send you a document. If you did not expect it, contact them. We will pass on a request if you cannot reach them. |
| The audit trail and evidence records | Independent controller | We keep this to meet our own legal and evidentiary obligations. Neither you nor the sender can instruct us to alter or selectively delete it, because a log that can be edited on request is not evidence. |
| Conversations with the agent, the drafts, answers and actions it prepares, and the facts it keeps in memory | Data Processor under the DPDP Act; processor under GDPR | The agent works on your workspace's content at the request of the people in it. A conversation is visible only to the person who had it. The facts it keeps for the workspace are visible to everyone in it, and the ones it keeps for one person only to that person. What the agent does to a document is also written to that document's audit trail. |
| The public record of completed documents | Independent controller | We publish each completed document's hash, reference code and completion time, so anyone can check a signed file against it. It holds no names, addresses or content, and entries are never removed. |
| Security, fraud prevention, abuse and rate limiting | Independent controller | We process this to keep the service safe for everyone, on our own responsibility. |
Where we act as a processor, our obligations to the account holder are set out in the data processing addendum, which forms part of our contract with them.
3.What we collect, why, and on what legal basis
Legal bases are cited under GDPR Articles 6 and 9. Under the DPDP Act the corresponding basis is consent under section 6, or a legitimate use under section 7 where you voluntarily provide data for a purpose and have not objected.
Category
Identity and account
What it includes
Name, email address, hashed password, and optionally job title, company name and profile image.
Why we process it
To create and secure your account, identify you, and contact you about the service.
Legal basis
Performance of a contract. Consent for optional fields.
Category
Authentication
What it includes
Session tokens stored only as hashes, with the network address and browser of each signed-in session, sign-in timestamps, your two-factor secret and recovery codes if you turn two-factor on, and, if you use single sign-on, the account identifier and email returned by Google, GitHub or Microsoft.
Why we process it
To keep you signed in and to let you revoke sessions.
Legal basis
Performance of a contract. Legitimate interests in account security.
Category
Account security
What it includes
Failed sign-ins to an account: a hash of its email address, the count and the time, kept to lock the account after repeated failures. The browsers and networks your account has signed in from, stored as a hash with a readable label such as "Chrome on macOS" and an approximate place, so we can email you when a password sign-in comes from somewhere new. Every failed sign-in is also written to our security log with the network address and the browser, and with the email address tried only when it belongs to an account.
Why we process it
To protect your account against password guessing and stolen passwords.
Legal basis
Legitimate interests in account security.
Category
Workspace
What it includes
Workspace name, branding, membership, roles and invitations.
Why we process it
To let teams share documents with the right permissions.
Legal basis
Performance of a contract.
Category
Document content
What it includes
The files you upload, the fields you place, values recipients enter, and signature images.
Why we process it
To deliver, display and complete your documents. We process this on the account holder's instructions.
Legal basis
Processor acting for the controller. The controller's own basis applies.
Category
Recipient details
What it includes
Recipient names, email addresses, assigned roles and signing order, supplied by the sender, or by a visitor who asks for a signing link through an open link. Such a visitor is also added to the workspace's contacts.
Why we process it
To deliver the right document to the right person in the right order.
Legal basis
Processor acting for the sender.
Category
Signer checks
What it includes
Where a sender turns them on: the access code the sender sets for a recipient, which is kept encrypted and shown only in the editor while the document is prepared; the 6-digit codes we email to signers, which are stored only as hashes and expire after 10 minutes; and the number of wrong attempts.
Why we process it
To make it harder for anyone but the intended signer to open a signing link.
Legal basis
Processor acting for the sender.
Category
Signatures and Signature IDs
What it includes
The signatures and initials you adopt and save, the name and initials they are adopted under, the adoption statement you agreed to, and your Signature ID, which is printed under every mark you make. If you sign a document at an address that has a DropTheDoc account, and that account has confirmed the address, the signature you made is saved to that account.
Why we process it
To let you sign with a signature you adopted once, and to tie every mark back to the person who made it.
Legal basis
Performance of a contract.
Category
The agent
What it includes
What you ask the agent and what it answers, the drafts it writes, the actions it proposes and what was decided, your workspace's house style, the automations you set up, and the short facts it keeps in memory because someone told it to, such as who signs for an organisation. It never keeps document text, signatures, what people filled in, codes or account numbers in memory.
Why we process it
To do what you asked the agent to do. The content a request needs goes to our AI provider, Anthropic, as clause 6 explains.
Legal basis
Processor acting for the account holder.
Category
Agent usage
What it includes
For each request the agent handles: the workspace, the person or automation it was for, the kind of request, its size and the credits it used.
Why we process it
To count credits against the monthly allowance, show a workspace what they went on, and stop abuse.
Legal basis
Performance of a contract. Legitimate interests in preventing abuse.
Category
Evidence and audit
What it includes
IP address, an approximate place our hosting provider reports for it at the time, browser user-agent, and UTC timestamps for every send, open, view, signer check, consent, signature, decline, reminder, extension, cancellation and expiry, whether a step was taken with the agent, plus document hashes, a hash of each signature image and the name and initials it was adopted under.
Why we process it
To prove who signed what, when and from where. This is what makes an electronic signature defensible and it cannot be disabled for a document in progress.
Legal basis
Legal obligation and legitimate interests in providing legally reliable evidence, and in establishing, exercising or defending legal claims.
Category
Contacts
What it includes
Names and email addresses you save to reuse when addressing documents.
Why we process it
To save you retyping them.
Legal basis
Performance of a contract.
Category
Developer access
What it includes
API keys, stored only as hashes with a short prefix you can recognise them by, the webhook addresses a workspace adds, and the status of recent deliveries.
Why we process it
To let a workspace connect its own systems.
Legal basis
Performance of a contract.
Category
Billing
What it includes
Plan, billing cycle, invoice history, GST registration number where you supply one, and the country and tax status we need to invoice correctly. Card details are handled by our payment processor and never reach our servers.
Why we process it
To charge you, to issue compliant tax invoices, and to meet accounting and tax law.
Legal basis
Performance of a contract. Legal obligation.
Category
Operational and security
What it includes
Rate limiting counters, error logs, and server logs containing IP address, request path and timestamp.
Why we process it
To keep the service running, to detect and stop abuse, and to investigate incidents.
Legal basis
Legitimate interests in security and service integrity.
Category
Communications
What it includes
Messages you send us through the contact form or by email, and our replies.
Why we process it
To answer you and to keep a record of what was agreed.
Legal basis
Legitimate interests in responding to enquiries. Consent where you initiated it.
| Category | What it includes | Why we process it | Legal basis |
|---|---|---|---|
| Identity and account | Name, email address, hashed password, and optionally job title, company name and profile image. | To create and secure your account, identify you, and contact you about the service. | Performance of a contract. Consent for optional fields. |
| Authentication | Session tokens stored only as hashes, with the network address and browser of each signed-in session, sign-in timestamps, your two-factor secret and recovery codes if you turn two-factor on, and, if you use single sign-on, the account identifier and email returned by Google, GitHub or Microsoft. | To keep you signed in and to let you revoke sessions. | Performance of a contract. Legitimate interests in account security. |
| Account security | Failed sign-ins to an account: a hash of its email address, the count and the time, kept to lock the account after repeated failures. The browsers and networks your account has signed in from, stored as a hash with a readable label such as "Chrome on macOS" and an approximate place, so we can email you when a password sign-in comes from somewhere new. Every failed sign-in is also written to our security log with the network address and the browser, and with the email address tried only when it belongs to an account. | To protect your account against password guessing and stolen passwords. | Legitimate interests in account security. |
| Workspace | Workspace name, branding, membership, roles and invitations. | To let teams share documents with the right permissions. | Performance of a contract. |
| Document content | The files you upload, the fields you place, values recipients enter, and signature images. | To deliver, display and complete your documents. We process this on the account holder's instructions. | Processor acting for the controller. The controller's own basis applies. |
| Recipient details | Recipient names, email addresses, assigned roles and signing order, supplied by the sender, or by a visitor who asks for a signing link through an open link. Such a visitor is also added to the workspace's contacts. | To deliver the right document to the right person in the right order. | Processor acting for the sender. |
| Signer checks | Where a sender turns them on: the access code the sender sets for a recipient, which is kept encrypted and shown only in the editor while the document is prepared; the 6-digit codes we email to signers, which are stored only as hashes and expire after 10 minutes; and the number of wrong attempts. | To make it harder for anyone but the intended signer to open a signing link. | Processor acting for the sender. |
| Signatures and Signature IDs | The signatures and initials you adopt and save, the name and initials they are adopted under, the adoption statement you agreed to, and your Signature ID, which is printed under every mark you make. If you sign a document at an address that has a DropTheDoc account, and that account has confirmed the address, the signature you made is saved to that account. | To let you sign with a signature you adopted once, and to tie every mark back to the person who made it. | Performance of a contract. |
| The agent | What you ask the agent and what it answers, the drafts it writes, the actions it proposes and what was decided, your workspace's house style, the automations you set up, and the short facts it keeps in memory because someone told it to, such as who signs for an organisation. It never keeps document text, signatures, what people filled in, codes or account numbers in memory. | To do what you asked the agent to do. The content a request needs goes to our AI provider, Anthropic, as clause 6 explains. | Processor acting for the account holder. |
| Agent usage | For each request the agent handles: the workspace, the person or automation it was for, the kind of request, its size and the credits it used. | To count credits against the monthly allowance, show a workspace what they went on, and stop abuse. | Performance of a contract. Legitimate interests in preventing abuse. |
| Evidence and audit | IP address, an approximate place our hosting provider reports for it at the time, browser user-agent, and UTC timestamps for every send, open, view, signer check, consent, signature, decline, reminder, extension, cancellation and expiry, whether a step was taken with the agent, plus document hashes, a hash of each signature image and the name and initials it was adopted under. | To prove who signed what, when and from where. This is what makes an electronic signature defensible and it cannot be disabled for a document in progress. | Legal obligation and legitimate interests in providing legally reliable evidence, and in establishing, exercising or defending legal claims. |
| Contacts | Names and email addresses you save to reuse when addressing documents. | To save you retyping them. | Performance of a contract. |
| Developer access | API keys, stored only as hashes with a short prefix you can recognise them by, the webhook addresses a workspace adds, and the status of recent deliveries. | To let a workspace connect its own systems. | Performance of a contract. |
| Billing | Plan, billing cycle, invoice history, GST registration number where you supply one, and the country and tax status we need to invoice correctly. Card details are handled by our payment processor and never reach our servers. | To charge you, to issue compliant tax invoices, and to meet accounting and tax law. | Performance of a contract. Legal obligation. |
| Operational and security | Rate limiting counters, error logs, and server logs containing IP address, request path and timestamp. | To keep the service running, to detect and stop abuse, and to investigate incidents. | Legitimate interests in security and service integrity. |
| Communications | Messages you send us through the contact form or by email, and our replies. | To answer you and to keep a record of what was agreed. | Legitimate interests in responding to enquiries. Consent where you initiated it. |
We do not collect personal data from third-party data brokers, we do not enrich your profile from external sources, and we run no advertising, analytics or behavioural tracking on any part of the service. The approximate place shown beside a network address comes from our hosting provider, which reports it with each request it delivers, so no other service receives the address, as subprocessors explains.
4.Sensitive and special category data
We do not ask for special category data under GDPR Article 9, or sensitive personal data under Rule 3 of the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011, except that passwords are treated as sensitive personal data under those Rules and are stored only as bcrypt hashes.
Documents are a different matter
You control what you upload. A contract can easily contain health information, biometric data, financial account details, government identifiers such as Aadhaar or PAN, or data about criminal matters. We do not inspect documents, so we cannot warn you, and the agent reads a document only when someone asks it to. If you upload special category or sensitive data, you are the controller of it, you need your own lawful basis and, under GDPR Article 9, an applicable exception. Under the SPDI Rules you need the data subject's written consent before collecting sensitive personal data.
For the avoidance of doubt: we do not sell sensitive personal data, we do not use or disclose it beyond providing the service you asked for, and there is therefore nothing for a Californian consumer to limit under the CCPA right to limit the use of sensitive personal information.
5.Children
DropTheDoc is a business tool and is not directed at children. You must be at least 18 to hold an account.
Section 9 of the DPDP Act treats everyone under 18 as a child and requires verifiable consent from a parent or lawful guardian before their personal data is processed. It also prohibits tracking, behavioural monitoring and targeted advertising directed at children. We do none of those things for any user, and we do not knowingly process a child's personal data.
In the EU and UK the digital-consent age is 16, or lower where a member state has set it lower, and in the United States COPPA applies below 13. Whichever threshold applies, if you believe a child's personal data has reached us, write to privacy@suresign.si and we will delete it, other than any audit entries we are required to retain, which we will anonymise.
8.Where your data goes
DropTheDoc is operated from India, and our infrastructure providers and our AI provider are established in the United States and operate globally. Personal data is therefore processed in India, in the United States, and in whichever region hosts the database and storage for your workspace. The full list of providers and their locations is at subprocessors.
- From India.
- Section 16 of the DPDP Act permits transfer outside India except to countries the Central Government restricts by notification. We monitor that list and will stop transfers to any restricted country.
- From the EEA.
- India has no adequacy decision under GDPR Article 45. We therefore rely on the Standard Contractual Clauses adopted by the European Commission in Decision (EU) 2021/914, incorporated into our data processing addendum, together with a transfer impact assessment and the supplementary measures described in clause 10 and in our security page. Encryption at rest and in transit, and our policy on government requests, are part of those measures.
- From the United Kingdom.
- The International Data Transfer Addendum to the EU SCCs, issued under section 119A of the Data Protection Act 2018.
- From Switzerland.
- The SCCs as amended for Swiss law, with the Federal Data Protection and Information Commissioner as the competent authority.
You can request a copy of the safeguards we rely on by writing to privacy@suresign.si. We may redact commercial terms.
9.How long we keep things
We keep personal data only while there is a reason to, and then delete or anonymise it. Section 8(7) of the DPDP Act requires erasure once the purpose is no longer served, and GDPR Article 5(1)(e) says the same thing differently.
Data
Account and profile
Retention
While your account is open, and 30 days after you close it.
Then what
Deleted.
Data
Documents and their contents
Retention
While your workspace holds them. You can delete any document at any time; a deleted document stays recoverable for your workspace's recovery window, 30 days by default.
Then what
Destroyed once the recovery window closes: removed from the database and from encrypted object storage. Backups age out on their own cycle. See the deletion and recovery policy.
Data
Completed documents and certificates
Retention
While your workspace exists, unless you delete them, because the evidence is the point of the product.
Then what
Deleted with the workspace, subject to the audit trail row below.
Data
Audit trail
Retention
Retained even after the related document is destroyed.
Then what
Kept. A document's entries are never removed, because removing them would break the hash chain and destroy the integrity guarantee for every other document. It holds no document content: no pages, field values or signature images. When an account is closed, its name, email address and network address are removed from the entries it made as an account holder. Otherwise personal data within it is anonymised on request where we can, under clause 12.
Data
Conversations with the agent, and their drafts
Retention
Until the person who had the conversation deletes it, an admin clears the workspace's chats, or it has had no new message for the workspace's chat window: 90 days by default, and 30, 60, 180 or 365 if an admin chooses. When a document is permanently deleted, what the agent read from it and any draft it wrote for it are removed from every conversation, and what was said stays until the conversation is deleted.
Then what
Deleted by the nightly maintenance job. What the agent did to documents stays in their audit trails and in the workspace's activity.
Data
Facts the agent keeps in memory
Retention
Until someone forgets them, from a chat or in Settings, Agent, Memory. A person's own facts go when they leave the workspace or close their account, and every fact goes with the workspace. Each plan keeps a fixed number.
Then what
Deleted at once. The audit trail records only that a fact was kept or forgotten, never the fact itself. The chat it was learned in keeps its words until that chat is deleted.
Data
Agent usage records
Retention
While the workspace exists.
Then what
Deleted with the workspace.
Data
Sessions
Retention
Up to 30 days, or until you sign out or change your password.
Then what
Purged automatically by the daily maintenance job.
Data
Failed sign-in records
Retention
The lockout count, until the next successful sign-in, until the account is closed, or until a day passes with no further failure and no lock running. The security log entry for each failed attempt, for 180 days, the rolling period Indian law asks such logs to be kept for.
Then what
Deleted. The daily maintenance job removes counts and log entries as they reach those limits.
Data
Browsers and networks an account has used
Retention
While the account exists, or until you forget them in security settings.
Then what
Deleted.
Data
Signer checks
Retention
An emailed code works for 10 minutes; an access code lasts as long as the document. Passing a check is remembered in that browser for 12 hours.
Then what
Both are deleted with the document when it is destroyed.
Data
The public record of completed documents
Retention
Permanently. It holds a hash, a reference code and a time, and no personal data on its own.
Then what
Never removed, because the record exists to prove nothing was. See the deletion and recovery policy.
Data
Signing links and one-time tokens
Retention
Until used, cancelled or expired, whichever is first.
Then what
Revoked immediately and purged.
Data
Server and security logs
Retention
Up to 90 days.
Then what
Deleted, unless an entry is part of an active security investigation.
Data
Billing records and tax invoices
Retention
Eight years from the end of the relevant financial year.
Then what
Retained. This is a legal obligation under the Companies Act, 2013 and Indian tax law, and we cannot delete it on request.
Data
Support correspondence
Retention
Three years from the last message.
Then what
Deleted.
| Data | Retention | Then what |
|---|---|---|
| Account and profile | While your account is open, and 30 days after you close it. | Deleted. |
| Documents and their contents | While your workspace holds them. You can delete any document at any time; a deleted document stays recoverable for your workspace's recovery window, 30 days by default. | Destroyed once the recovery window closes: removed from the database and from encrypted object storage. Backups age out on their own cycle. See the deletion and recovery policy. |
| Completed documents and certificates | While your workspace exists, unless you delete them, because the evidence is the point of the product. | Deleted with the workspace, subject to the audit trail row below. |
| Audit trail | Retained even after the related document is destroyed. | Kept. A document's entries are never removed, because removing them would break the hash chain and destroy the integrity guarantee for every other document. It holds no document content: no pages, field values or signature images. When an account is closed, its name, email address and network address are removed from the entries it made as an account holder. Otherwise personal data within it is anonymised on request where we can, under clause 12. |
| Conversations with the agent, and their drafts | Until the person who had the conversation deletes it, an admin clears the workspace's chats, or it has had no new message for the workspace's chat window: 90 days by default, and 30, 60, 180 or 365 if an admin chooses. When a document is permanently deleted, what the agent read from it and any draft it wrote for it are removed from every conversation, and what was said stays until the conversation is deleted. | Deleted by the nightly maintenance job. What the agent did to documents stays in their audit trails and in the workspace's activity. |
| Facts the agent keeps in memory | Until someone forgets them, from a chat or in Settings, Agent, Memory. A person's own facts go when they leave the workspace or close their account, and every fact goes with the workspace. Each plan keeps a fixed number. | Deleted at once. The audit trail records only that a fact was kept or forgotten, never the fact itself. The chat it was learned in keeps its words until that chat is deleted. |
| Agent usage records | While the workspace exists. | Deleted with the workspace. |
| Sessions | Up to 30 days, or until you sign out or change your password. | Purged automatically by the daily maintenance job. |
| Failed sign-in records | The lockout count, until the next successful sign-in, until the account is closed, or until a day passes with no further failure and no lock running. The security log entry for each failed attempt, for 180 days, the rolling period Indian law asks such logs to be kept for. | Deleted. The daily maintenance job removes counts and log entries as they reach those limits. |
| Browsers and networks an account has used | While the account exists, or until you forget them in security settings. | Deleted. |
| Signer checks | An emailed code works for 10 minutes; an access code lasts as long as the document. Passing a check is remembered in that browser for 12 hours. | Both are deleted with the document when it is destroyed. |
| The public record of completed documents | Permanently. It holds a hash, a reference code and a time, and no personal data on its own. | Never removed, because the record exists to prove nothing was. See the deletion and recovery policy. |
| Signing links and one-time tokens | Until used, cancelled or expired, whichever is first. | Revoked immediately and purged. |
| Server and security logs | Up to 90 days. | Deleted, unless an entry is part of an active security investigation. |
| Billing records and tax invoices | Eight years from the end of the relevant financial year. | Retained. This is a legal obligation under the Companies Act, 2013 and Indian tax law, and we cannot delete it on request. |
| Support correspondence | Three years from the last message. | Deleted. |
If you close your workspace, export what you need first. After the 30-day window, deletion is irreversible, and because documents are encrypted at rest we cannot reconstruct them. The same is true of an individual document once its recovery window has closed; the deletion and recovery policy sets out exactly what is destroyed and what survives.
10.How we protect it
Documents are encrypted at rest with AES-256-GCM and in transit with TLS. Passwords are hashed with bcrypt. Session tokens are stored only as SHA-256 hashes. Access is scoped to your workspace and checked on every request, not just in the interface, and the agent is held to the same checks as the person using it. Uploads are size-limited, type-checked and checked for malware. The audit trail is append-only and hash-chained, and completed documents are anchored in a public record.
Rule 8 of the SPDI Rules, 2011 requires reasonable security practices proportionate to the data held. The controls we operate are described in detail on the security page, and the contractual version of them is Annex II of the data processing addendum.
No system is perfectly secure. If something happens, clause 13 explains what we do about it.
11.Your rights
Your rights depend on where you live. We apply the strongest applicable standard rather than the minimum, and we do not charge for exercising a right unless a request is manifestly unfounded or excessive, in which case we will tell you before doing anything.
Where you are
India (DPDP Act, 2023)
What you can do
Obtain a summary of the personal data we process and who we have shared it with (section 11). Correct, complete, update or erase your data (section 12). Have a grievance addressed by us before approaching the Data Protection Board (section 13). Nominate someone to exercise your rights if you die or become incapacitated (section 14). Withdraw consent at any time, as easily as you gave it (section 6(6)).
Where you are
EEA and UK (GDPR)
What you can do
Access your data and receive a copy (Article 15). Rectification (16). Erasure (17). Restriction (18). Portability in a structured, machine-readable format (20). Object to processing based on legitimate interests (21). Withdraw consent at any time without affecting prior processing (7(3)). Complain to your supervisory authority (77), and in the UK to the Information Commissioner's Office.
Where you are
California (CCPA/CPRA)
What you can do
Know what we collect, use, disclose and sell. Delete. Correct. Portability. Opt out of sale or sharing, which does not arise because we do neither. Limit the use of sensitive personal information, which also does not arise. Non-discrimination for exercising any right. Use an authorised agent.
Where you are
Other US states
What you can do
Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, and other states with comprehensive privacy statutes: access, correction, deletion, portability, opt-out of targeted advertising, sale and certain profiling, and appeal a refusal.
Where you are
Canada, Australia, Brazil, elsewhere
What you can do
Access, correction and complaint rights under PIPEDA, the Privacy Act 1988 and the Australian Privacy Principles, the LGPD, and comparable laws. Tell us where you are and we will apply the right framework.
| Where you are | What you can do |
|---|---|
| India (DPDP Act, 2023) | Obtain a summary of the personal data we process and who we have shared it with (section 11). Correct, complete, update or erase your data (section 12). Have a grievance addressed by us before approaching the Data Protection Board (section 13). Nominate someone to exercise your rights if you die or become incapacitated (section 14). Withdraw consent at any time, as easily as you gave it (section 6(6)). |
| EEA and UK (GDPR) | Access your data and receive a copy (Article 15). Rectification (16). Erasure (17). Restriction (18). Portability in a structured, machine-readable format (20). Object to processing based on legitimate interests (21). Withdraw consent at any time without affecting prior processing (7(3)). Complain to your supervisory authority (77), and in the UK to the Information Commissioner's Office. |
| California (CCPA/CPRA) | Know what we collect, use, disclose and sell. Delete. Correct. Portability. Opt out of sale or sharing, which does not arise because we do neither. Limit the use of sensitive personal information, which also does not arise. Non-discrimination for exercising any right. Use an authorised agent. |
| Other US states | Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, and other states with comprehensive privacy statutes: access, correction, deletion, portability, opt-out of targeted advertising, sale and certain profiling, and appeal a refusal. |
| Canada, Australia, Brazil, elsewhere | Access, correction and complaint rights under PIPEDA, the Privacy Act 1988 and the Australian Privacy Principles, the LGPD, and comparable laws. Tell us where you are and we will apply the right framework. |
If someone sent you a document, we hold your data as a processor for them. Send access, correction or deletion requests to that sender. If you cannot identify or reach them, write to us and we will either forward the request or tell you who to ask.
One limit on erasure
We cannot delete audit entries for a document that has been signed. That record is what makes the signature provable, other parties to the document have a legal interest in it, and a hash chain with entries removed no longer proves anything for anyone else either. We anonymise the personal identifiers in it instead. This is permitted by GDPR Article 17(3)(b) and (e), and by the corresponding exemptions in section 17 of the DPDP Act.
12.How to exercise a right
Email privacy@suresign.si from the address on your account, or write to the Grievance Officer named in clause 15. Tell us what you want and which jurisdiction you are in.
We verify identity before acting, because handing someone's contract history to the wrong person is worse than being slow. For most requests, control of the account email is enough. For deletion or a large export we may ask for more. An authorised agent must supply written permission signed by you.
Request type
Grievance under the DPDP Act or the SPDI Rules
We acknowledge
Within 24 hours
We complete
Within 15 days, and in any case within the period the applicable rules require
Request type
GDPR or UK GDPR rights request
We acknowledge
Promptly
We complete
Within one month, extendable by two further months for complex requests, which we will tell you about within the first month
Request type
CCPA request
We acknowledge
Within 10 business days
We complete
Within 45 days, extendable once by a further 45 days with notice
Request type
Anything else
We acknowledge
Within 3 business days
We complete
Within 30 days
| Request type | We acknowledge | We complete |
|---|---|---|
| Grievance under the DPDP Act or the SPDI Rules | Within 24 hours | Within 15 days, and in any case within the period the applicable rules require |
| GDPR or UK GDPR rights request | Promptly | Within one month, extendable by two further months for complex requests, which we will tell you about within the first month |
| CCPA request | Within 10 business days | Within 45 days, extendable once by a further 45 days with notice |
| Anything else | Within 3 business days | Within 30 days |
You can export your own documents and certificates from the dashboard at any time without asking us.
13.If there is a data breach
If personal data is breached, we will investigate immediately, contain it, and notify as follows:
- India. The Data Protection Board of India and every affected Data Principal, as required by section 8(6) of the DPDP Act and the rules made under it, without the delay those rules prohibit. We will also report to CERT-In within 6 hours of becoming aware where the incident falls within the categories in its directions of 28 April 2022.
- EEA and UK. The lead supervisory authority within 72 hours of becoming aware, under GDPR Article 33, and affected individuals without undue delay where the risk to their rights and freedoms is high, under Article 34.
- United States. Affected individuals and regulators within the deadlines set by the applicable state breach notification statutes.
- Our customers. Where we act as a processor, we notify the affected account holder without undue delay so that they can meet their own notification obligations, and we give them the information they need to do it.
Notifications will describe what happened, what data was involved, what we have done, and what you should do.
14.Automated decisions and profiling
We do not make decisions producing legal or similarly significant effects about you by automated means, and we do not profile you. Rate limiting, abuse detection and the sign-in lockout are automated, but they throttle or block a request rather than decide anything about you as a person, and you can reach a human at support@suresign.si if you are affected.
The agent does not make decisions about anyone either. It drafts, answers and proposes, and a person decides: anything it would send to someone waits for a person to approve it, except reminders and extensions that a workspace admin has allowed automations to send on their own.
15.Who to contact
Grievance Officer (India)
Appointed under section 13 of the DPDP Act, 2023, Rule 5(9) of the SPDI Rules, 2011 and Rule 3(2) of the IT (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021.
Yash Raj
Genflix Commerce Private Limited, Kamal Nagar Colony, Mirjanhat Bhagalpur,Bihar 812005
Email: grievance@suresign.si
See the grievance redressal policy for how complaints are handled and escalated.
Representatives in the EU and UK
EU representative under GDPR Article 27: [your Article 27 representative in the EU]
UK representative under UK GDPR Article 27: [your UK representative]
You always have the right to complain to your own regulator. In India that is the Data Protection Board of India, in the EEA your national supervisory authority, and in the UK the Information Commissioner's Office. We would rather you came to us first, but nothing here requires it.
16.Changes to this policy
We will update this policy when the service or the law changes. The version number and effective date at the top always tell you which version you are reading, and clause history is listed at the foot of the page.
For material changes that reduce your rights or expand how we use personal data, we will give account holders at least 30 days' notice by email before they take effect. For clarifications and corrections we will update the page and bump the version.
Version history
- Version 3.315 October 2026
Added the agent's memory: the short facts it keeps because someone told it to, who can see them, what it never keeps, and how long they are kept.
- Version 3.215 October 2026
An account sees documents sent to its address, and keeps the signatures made at that address, only once it has confirmed the address is its own. Clauses 3 and 6 now say so.
- Version 3.115 October 2026
Access codes are now kept encrypted and are never sent to our AI provider. The approximate place beside a network address now comes from our hosting provider, so no geolocation service receives addresses. Permanently deleting a document now also removes what the agent read from it, and any draft it wrote for it, from every conversation. Failed sign-ins: the lockout count no longer holds a network address and is cleared after a quiet day or when the account is closed, the security log no longer records an email address that has no account, and its failed sign-in entries are deleted after 180 days.
- Version 3.015 October 2026
Added the agent: what it processes, that its AI provider is Anthropic and may not train on your content, who can see a conversation, and how long conversations and usage records are kept. Added account security records (failed sign-ins, the browsers and networks an account has used, two-factor), signer checks, saved signatures and Signature IDs, open links, API keys and webhooks, read-only access for people a document was sent to, the /verify check, the public record of completed documents, and the approximate place looked up from a network address. The audit trail row now says which identifiers are removed when an account is closed. Corrected four clause references.
- Version 2.127 July 2026
Retention schedule updated for the document recovery window: deleting a document now moves it to a Deleted tab and destroys it when the window closes. Corrected the audit-trail row, which said personal identifiers were anonymised automatically on deletion. The chain is kept intact and anonymisation is handled as a data subject request under clause 12. Added cross-references to the new deletion and recovery policy.
- Version 2.026 July 2026
Rewritten for the DPDP Act, 2023, the SPDI Rules, 2011, GDPR Articles 13 and 14, and the CCPA as amended. Added the controller and processor split, the retention schedule, transfer mechanisms, response deadlines, breach notification timelines, and the Grievance Officer contact.
- Version 1.01 July 2026
First publication.
This document describes how DropTheDoc works and what we and you have agreed. It is written to track the law it cites, but it is not legal advice and it is not a substitute for advice about your own situation. Statutes change. If you are relying on this for something that matters, have your own counsel review it, and any document you send, before you rely on it.