Data processing agreement

Last updated 16 September 2026. Neptune Atlas is a product of Neptune Labs.

These documents describe how the product actually works, clause by clause, against the code. They have not been reviewed by a lawyer. Neptune Labs holds no SOC 2 report and no ISO 27001 certificate, and nothing here should be read as claiming otherwise. Where a fact belongs in a legal document and this build cannot read it out of the code, it is left as a visible bracket rather than filled in with something plausible. Send this to your own counsel; that is what it is for.

What this is and when it applies

This agreement governs our processing of personal data that you put into Neptune Atlas. It applies automatically from the moment you create an account, forms part of the terms of service, and needs no signature to take effect. If your procurement requires a countersigned copy, write to support@neptunelabs.ca and we will sign this document; we would rather sign our own paper than a template neither of us has read against the product.

It is written as the Article 28 contract required by the GDPR and the UK GDPR. Where you are subject to another regime instead, the same obligations are offered on the same terms.

Last updated 16 September 2026. It has not been reviewed by a lawyer, which the banner at the top of this page says for a reason.

Who is who

You are the controller of the personal data in your desk: your own people, your counterparties, the senders of mail that reaches you, and anybody named in a document you import. You decide what goes in and what it is for.

Neptune Labs is the processor of that data. We hold it to run the product for you and we decide nothing about it.

Neptune Labs is the controller, separately and on its own account, of your account relationship, our billing records, the security audit trail, the shared vessel and company register, and any call between your people and our support line. That processing is not governed by this agreement; it is described in the privacy notice. The distinction matters when a request arrives: you answer for the contents of your desk and we answer for the rest.

The marketplace is the awkward one and is named as such. When you post cargo or open tonnage to the board, we decide that the board exists, who may read it and how long a listing lives, which makes us closer to a controller than a processor for those rows. Treat a posting as a disclosure you are making, not as data you are entrusting to us.

Processing only on your instructions

We process your personal data only on your documented instructions, including on transfers to a third country, unless a law we are subject to requires otherwise. Where that happens we will tell you before processing, unless the law forbids us from telling you on important grounds of public interest.

What counts as your documented instruction. These terms, this agreement, the settings you choose, and your ordinary use of the product. Pressing a button that sends a document to a reader is an instruction to send it; connecting a mailbox is an instruction to index it; posting a listing is an instruction to publish it. There is no other route by which your data is processed.

If we think an instruction of yours infringes data protection law, we will tell you and may decline until it is resolved.

We do not use your data to train machine learning models, our own or anybody else's, and we do not permit any party in Annex 3 to do so with data we send them.

Confidentiality

Everybody at Neptune Labs authorised to process your data is bound to confidentiality by their contract of engagement, and that obligation survives the end of it. Access is limited to the people who need it to run the service, answer a support request, or make a verification decision.

Named plainly rather than left to be discovered: a Neptune Labs operator can read a verification document you upload and a screenshot you attach to a bug report, because those are the only way to do the thing you asked for. Operators do not read the contents of a connected mailbox, which is restricted in the database query to the person who connected it.

Security

We maintain the technical and organisational measures set out in Annex 2, having regard to the state of the art, the cost of implementation, and the nature and risk of the processing.

Those measures may change as the product changes. They will not be reduced below the level described in Annex 2 for the term of your subscription.

Sub-processors

You give a general authorisation for us to engage the sub-processors listed at neptuneatlas.com/subprocessors, which is the single authoritative list and is reproduced at Annex 3. Each is used under the data processing terms that provider publishes for its service. We have not yet confirmed and filed a dated copy of each one, and until we have we do not claim that every one imposes obligations no less protective than these. We remain fully liable to you for their performance either way.

Notice before a change. We will publish an intended addition or replacement to that page, with a dated entry in its change log, and e-mail the account owner at least 30 days before the new sub-processor starts. The announcement comes first and the change follows it; that ordering is the whole value of the clause.

Your right to object. Within those 30 days you may object on reasonable data protection grounds by writing to support@neptunelabs.ca. We will work with you to find an alternative arrangement. If none is available, you may terminate the affected part of the service without penalty and we will refund the unused part of any period paid in advance.

One honest caveat, because the alternative is a promise that breaks the first time it is tested: where a sub-processor must be replaced urgently for security or continuity, we may make the change first and tell you without delay, and your right to object and terminate is unaffected.

Helping you answer a data subject

Taking account of the nature of the processing, we will help you meet your obligations under Articles 12 to 22 by appropriate technical and organisational measures.

Requests that come to us by mistake. A data subject frequently writes to the vendor rather than to the desk. We will not answer on your behalf. We will forward the request to the account owner without undue delay, tell the person we have done so and who the controller is, and then wait for your instruction.

What we can do for you. Produce a copy of everything in your desk relating to a named person, restrict or delete records on your instruction, and export the desk in a portable form. There is no self-service export screen today, so this is a request to support@neptunelabs.ca and we answer within 30 days. Saying that plainly is better than describing a button that does not exist.

Assistance is included in your subscription for a reasonable volume of requests. We will tell you before charging for anything beyond that, and we will not make an answer conditional on payment.

Helping you with security, breaches and assessments

We will assist you in meeting your obligations under Articles 32 to 36, taking account of the nature of the processing and the information available to us.

A personal data breach affecting your data: we will notify the account owner without undue delay and in any event within 48 hours of becoming aware, and give you the nature of the breach, the categories and approximate number of records, the likely consequences, and what we are doing about it. Where we do not yet know something we will say we do not know it rather than delaying the notice until we do, and follow up as we learn more. Notifying your supervisory authority is yours to do; we will give you what you need to do it.

Data protection impact assessments and prior consultation: we will provide the information about our processing that you reasonably need, including the contents of Annexes 1 to 4 and answers to a security questionnaire.

Return and deletion at the end

At the end of the subscription you choose, by writing to support@neptunelabs.ca, whether your data is returned to you or deleted.

If you choose neither, the default is deletion. The desk is retained for 30 days after cancellation so that an accidental cancellation is recoverable, then the desk is listed as due by a daily check and we run the deletion. It removes the desk's schema, its stored files, its mailbox connections, its users' personal data and the IP addresses on its audit records, and writes a receipt recording which tables were deleted, how many rows, and what was kept and under which exemption. The receipt is available to you on request.

What survives, and why. Invoices and subscription records, for seven years, because a tax authority may ask. Verification documents, for seven years, as the evidence behind a decision we may have to explain. Security audit records with the personal fields stripped. Any address on the platform-wide do-not-contact list, which must survive precisely so that a person who asked not to be written to is not written to again. And backups for their rotation, described below.

Backups are named rather than glossed. A nightly database dump is held on the same machine for 14 days, so data deleted from the live database persists in a backup for up to 14 days. An earlier version of this clause also described an offsite copy of our customer records under a 90 day lifecycle; nothing we run makes one, and the sentence is withdrawn. Backups are not restored selectively to serve a deletion request, which no honest vendor does; they age out, and a restore that reintroduced deleted data would be re-run through the deletion.

Audit and information

We will make available to you the information necessary to demonstrate compliance with Article 28, and allow for and contribute to audits, including inspections, conducted by you or an auditor you mandate.

We have no certification to offer you instead. This is the clause where a vendor normally satisfies the audit right by handing over a SOC 2 Type II report. Neptune Labs holds no SOC 2 report and no ISO 27001 certificate, so the right below is the real one rather than a redirection.

In practice: on 30 days written notice, no more than once in twelve months unless a breach or a regulator's instruction makes it necessary, during business hours, subject to confidentiality, and conducted so as not to disrupt the service or reach another customer's data. We will answer a security questionnaire, provide the report from our most recent independent penetration test with any live findings redacted, and answer specific questions about the measures in Annex 2. You bear your own costs, and ours where an audit goes beyond one visit a year.

International transfers

Your data is stored in India. The application and its database run in Mumbai, in the AWS ap-south-1 region. India has no adequacy decision under Article 45. If you are established in the EEA or the UK, or your data subjects are, this is a restricted transfer and you should read Annex 4 before you sign anything.

The intended mechanism is set out in Annex 4: it is under review by counsel and is not complete, and the annex says which parts are unsettled. What it will not be is reliance on somebody else's clauses. The previous version of our privacy notice said transfers rode on "the provider's standard contractual clauses", which was not a mechanism at all on the transfer that matters, because on that one we are the importer ourselves.

Liability, and which document wins

The liability provisions of the terms of service apply to this agreement and to any claim arising under it, except where a statute forbids that limit.

Where this agreement and the terms of service conflict on the processing of personal data, this agreement wins. Where this agreement and the standard contractual clauses at Annex 4 conflict, the clauses win, as they require.

This agreement lasts as long as we process personal data for you, which is longer than the subscription: it covers the retention window and the deletion at the end of it.

Annex 1: the parties and the processing

Processor. Neptune Labs Inc. (corporation number 1001748164, [to be supplied: the jurisdiction Neptune Labs Inc. is incorporated in]), of [to be supplied: a postal address for commercial e-mail, required by CAN-SPAM and CASL]. Contact for data protection: support@neptunelabs.ca, [to be supplied: the name or role title of the person answering privacy requests, if it is not to be the support address]. EU representative under Article 27: [to be supplied: an EU Article 27 representative, or a recorded decision that Article 3(2) does not bite]. UK representative: [to be supplied: a UK Article 27 representative, or the same recorded decision].

Controller. The customer named on the account, at the address held on its billing record.

Subject matter and duration. Providing the Neptune Atlas ship broking platform, for the term of the subscription plus the retention and deletion windows described above.

Nature and purpose. Storage, structuring, retrieval, indexing, transcription of documents the customer uploads, transmission of mail the customer sends and receives, publication of listings the customer posts, and deletion.

Frequency. Continuous, for as long as the desk is in use.

Categories of data subject and of personal data:

Data subjects	Personal data	Sensitive or special category
Your own people: brokers, operators and administrators with a sign-in	Name, work e-mail, telephone, password hash, sign-in and audit history with IP address and browser, saved searches and screen layouts	None
Your counterparties: charterers, owners, managers, agents, principals	Name, role, employer, work e-mail, telephone, and whatever a broker writes in a note against them	None expected. A free-text note can hold anything a broker types
People who write to your desk	Sender address, recipients, subject, date and the message as sent, where it reaches an intake address or a connected mailbox	The contents of communications, which several regimes treat as a heightened category
Seafarers named on a document you import	The master's name and handwritten remarks on a statement of facts, and the times a named vessel was at a named berth	Location data tying an identified person to a place and time. Not a special category under Art. 9, and treated carefully all the same
Seafarers and others named in a file you attach	Crew lists, certificates, passports and other documents a broker attaches to a record, as uploaded	Can include health data, such as a medical fitness certificate, and identity documents. The product cannot see inside a file and does not screen for them
Port agents and officials named in a line-up	The agent's name against a line-up row	None

Your own people: brokers, operators and administrators with a sign-in
Personal data
Name, work e-mail, telephone, password hash, sign-in and audit history with IP address and browser, saved searches and screen layouts
Sensitive or special category
None
Your counterparties: charterers, owners, managers, agents, principals
Personal data
Name, role, employer, work e-mail, telephone, and whatever a broker writes in a note against them
Sensitive or special category
None expected. A free-text note can hold anything a broker types
People who write to your desk
Personal data
Sender address, recipients, subject, date and the message as sent, where it reaches an intake address or a connected mailbox
Sensitive or special category
The contents of communications, which several regimes treat as a heightened category
Seafarers named on a document you import
Personal data
The master's name and handwritten remarks on a statement of facts, and the times a named vessel was at a named berth
Sensitive or special category
Location data tying an identified person to a place and time. Not a special category under Art. 9, and treated carefully all the same
Seafarers and others named in a file you attach
Personal data
Crew lists, certificates, passports and other documents a broker attaches to a record, as uploaded
Sensitive or special category
Can include health data, such as a medical fitness certificate, and identity documents. The product cannot see inside a file and does not screen for them
Port agents and officials named in a line-up
Personal data
The agent's name against a line-up row
Sensitive or special category
None

The product does not require special categories of data under Article 9 or criminal conviction data under Article 10, and it cannot keep them out. A desk handles crew lists and seafarer documents, so a file attached to a record can carry health data or an identity document, and a free-text note holds whatever a broker types. Where that happens you are the controller deciding to process it, and it is held under the same measures as the rest of your desk. It is not screened, classified or given extra protection by the product, and any Article 9 condition your processing needs is yours to hold.

Annex 2: technical and organisational measures

Measure	How it is implemented
Separation of customers	Each desk is a separate Postgres schema rather than a customer column on a shared table. On every request the application reads the signed-in person's desk from the database and addresses only that desk's schema. The separation is enforced by the application: the database does not use a separate login per desk, and we do not describe it as more than that.
Encryption in transit	TLS on every connection to the application and to every third party in the list at Annex 3.
Encryption at rest	Mail credentials, vendor API keys, second-factor secrets and other stored credentials are encrypted by the application with a key held outside the database. Stored intake mail objects are encrypted server-side by the storage service. Passwords are hashed with Argon2id and are not recoverable. The database as a whole, and its nightly backup, are not described here as encrypted at rest, because that has not been confirmed.
Access control	Named accounts per person, no shared logins, role-based rights inside a desk, and a separate operator flag for Neptune Labs staff that is checked in the query rather than in the interface. Operator actions are refused to an operator who has not enrolled a second factor.
Accountability	An audit record is written before every destructive action taken through the application, carrying the actor, the time and the human reference of the record affected. The IP address and browser on those records are stripped after two years and the event itself is kept.
Resilience	A nightly logical backup that verifies its own payload, and a weekly restore test that fails if the restored database is empty. Both are named in Annex 2(f) terms rather than claimed as more than they are: see the limitation stated below.
Session security	Refresh tokens are single-use with reuse detection: a token presented twice invalidates the session it came from. A sign-in lasts at most 30 days however often it is used. Repeated failed sign-ins lock the account, and each further lockout lasts longer. Every person can see and end their own sessions, a desk admin can sign a member out, and a desk owner can require a second factor for every member. Turning a second factor off needs the password and a current code, and is e-mailed to the account holder.
Secure development	Migrations are reviewed, secrets are never committed, and the application refuses to start in production with a development signing or encryption key.
Testing	An independent penetration test in August 2026 produced 24 findings in the application code, all fixed and shipped, and six in the infrastructure, which remain open.

Separation of customers
How it is implemented
Each desk is a separate Postgres schema rather than a customer column on a shared table. On every request the application reads the signed-in person's desk from the database and addresses only that desk's schema. The separation is enforced by the application: the database does not use a separate login per desk, and we do not describe it as more than that.
Encryption in transit
How it is implemented
TLS on every connection to the application and to every third party in the list at Annex 3.
Encryption at rest
How it is implemented
Mail credentials, vendor API keys, second-factor secrets and other stored credentials are encrypted by the application with a key held outside the database. Stored intake mail objects are encrypted server-side by the storage service. Passwords are hashed with Argon2id and are not recoverable. The database as a whole, and its nightly backup, are not described here as encrypted at rest, because that has not been confirmed.
Access control
How it is implemented
Named accounts per person, no shared logins, role-based rights inside a desk, and a separate operator flag for Neptune Labs staff that is checked in the query rather than in the interface. Operator actions are refused to an operator who has not enrolled a second factor.
Accountability
How it is implemented
An audit record is written before every destructive action taken through the application, carrying the actor, the time and the human reference of the record affected. The IP address and browser on those records are stripped after two years and the event itself is kept.
Resilience
How it is implemented
A nightly logical backup that verifies its own payload, and a weekly restore test that fails if the restored database is empty. Both are named in Annex 2(f) terms rather than claimed as more than they are: see the limitation stated below.
Session security
How it is implemented
Refresh tokens are single-use with reuse detection: a token presented twice invalidates the session it came from. A sign-in lasts at most 30 days however often it is used. Repeated failed sign-ins lock the account, and each further lockout lasts longer. Every person can see and end their own sessions, a desk admin can sign a member out, and a desk owner can require a second factor for every member. Turning a second factor off needs the password and a current code, and is e-mailed to the account holder.
Secure development
How it is implemented
Migrations are reviewed, secrets are never committed, and the application refuses to start in production with a development signing or encryption key.
Testing
How it is implemented
An independent penetration test in August 2026 produced 24 findings in the application code, all fixed and shipped, and six in the infrastructure, which remain open.

Known limitations, stated rather than omitted. The nightly database backup is written to the same machine as the database, so it does not survive the loss of that machine; an off-box copy is an open item. There is no formal information security management system, no certification, and no dedicated security team. There is one production environment in one region. A buyer who needs any of those should know it before signing rather than after.

Annex 3: authorised sub-processors

The list below is a copy of neptuneatlas.com/subprocessors, which is the authoritative version and carries the dated change log. Where the two ever differ, that page is the one that governs; this annex is rendered from the same source so that they cannot.

Sub-processor	Purpose	What reaches them	Location
Amazon Web Services	The application and its Postgres database	Everything in a desk, and every account record	Mumbai, India (ap-south-1)
Amazon S3	Raw intake mail bodies, desk documents and attachments, call audio	Mail as sent, files a desk uploaded, recordings of calls to us	Mumbai, India for documents and attachments; call audio in Canada (ca-central-1); intake mail in a region not yet confirmed
Amazon SQS	The queue a message sits in between arriving and being read	The recipient token and a pointer to the stored message	Region not yet confirmed
AWS Lambda	Two small functions on the telephony path: caller lookup, and collecting the transcript	A calling number, and a finished call's transcript	Canada (ca-central-1)
AWS Amplify and CloudFront	Serving the site and its static files	Your IP address and the pages you asked for	Global edge network
Amazon Simple Email Service	Sending e-mail we originate, and receiving mail sent to a desk's intake address	Verification codes, password resets, support replies, inbound mail	Canada (ca-central-1)
Amazon Connect	The telephone line Neptune Labs answers on	Numbers, times, durations, and audio where recording is on	Canada (ca-central-1)
Amazon Contact Lens	Automated analysis of a recorded call: transcription, speaker labels, a summary	The words spoken on a call to or from Neptune Labs	Canada (ca-central-1)
Anthropic	Reading a scanned statement of facts, and researching a hull's ownership	The whole document as uploaded, including handwriting and names	United States
Microsoft	Graph and Entra ID, where a broker connects a Microsoft 365 or Outlook.com mailbox	Listings and message bodies from that mailbox, under Mail.Read and Mail.Send	United States and Ireland
Google Programmable Search	Finding a shipping company's own website, so the register can hold a real address	A company name and a country. Nothing of a customer's	United States
Google Analytics	Counting visits and which screens are used, once analytics is allowed	Pages, approximate location from IP, device, and your account and user numbers	United States and Ireland
Zoho Mail (Canadian data centre)	Our own mailbox, including the address every privacy request arrives at	Anything you write to us, including a data subject request	Canada
Stripe	Taking payment and holding card details	Billing name, e-mail, address, country and the card itself	United States and Ireland
Odoo S.A. (Odoo Online)	Our CRM: customer and prospect records, subscriptions, draft invoices, and the log of calls to our own telephone line	Desk and user names, work e-mails and telephone numbers, plan and usage counts, and notes and transcripts of calls to us	Region not yet confirmed with Odoo
Datalastic	The vessel register, ownership records and AIS positions	Which hull or which sea area was asked for. No customer identity	European Union
Cloudflare	DNS for the domain and the www redirect	The name your browser looked up	Global edge network
OpenFreeMap and AWS Terrain Tiles	Map tiles, fetched by your browser when a chart is on screen	Your IP address and the tile coordinates. Not who you are	Global edge network

Amazon Web Services
Purpose
The application and its Postgres database
What reaches them
Everything in a desk, and every account record
Location
Mumbai, India (ap-south-1)
Amazon S3
Purpose
Raw intake mail bodies, desk documents and attachments, call audio
What reaches them
Mail as sent, files a desk uploaded, recordings of calls to us
Location
Mumbai, India for documents and attachments; call audio in Canada (ca-central-1); intake mail in a region not yet confirmed
Amazon SQS
Purpose
The queue a message sits in between arriving and being read
What reaches them
The recipient token and a pointer to the stored message
Location
Region not yet confirmed
AWS Lambda
Purpose
Two small functions on the telephony path: caller lookup, and collecting the transcript
What reaches them
A calling number, and a finished call's transcript
Location
Canada (ca-central-1)
AWS Amplify and CloudFront
Purpose
Serving the site and its static files
What reaches them
Your IP address and the pages you asked for
Location
Global edge network
Amazon Simple Email Service
Purpose
Sending e-mail we originate, and receiving mail sent to a desk's intake address
What reaches them
Verification codes, password resets, support replies, inbound mail
Location
Canada (ca-central-1)
Amazon Connect
Purpose
The telephone line Neptune Labs answers on
What reaches them
Numbers, times, durations, and audio where recording is on
Location
Canada (ca-central-1)
Amazon Contact Lens
Purpose
Automated analysis of a recorded call: transcription, speaker labels, a summary
What reaches them
The words spoken on a call to or from Neptune Labs
Location
Canada (ca-central-1)
Anthropic
Purpose
Reading a scanned statement of facts, and researching a hull's ownership
What reaches them
The whole document as uploaded, including handwriting and names
Location
United States
Microsoft
Purpose
Graph and Entra ID, where a broker connects a Microsoft 365 or Outlook.com mailbox
What reaches them
Listings and message bodies from that mailbox, under Mail.Read and Mail.Send
Location
United States and Ireland
Google Programmable Search
Purpose
Finding a shipping company's own website, so the register can hold a real address
What reaches them
A company name and a country. Nothing of a customer's
Location
United States
Google Analytics
Purpose
Counting visits and which screens are used, once analytics is allowed
What reaches them
Pages, approximate location from IP, device, and your account and user numbers
Location
United States and Ireland
Zoho Mail (Canadian data centre)
Purpose
Our own mailbox, including the address every privacy request arrives at
What reaches them
Anything you write to us, including a data subject request
Location
Canada
Stripe
Purpose
Taking payment and holding card details
What reaches them
Billing name, e-mail, address, country and the card itself
Location
United States and Ireland
Odoo S.A. (Odoo Online)
Purpose
Our CRM: customer and prospect records, subscriptions, draft invoices, and the log of calls to our own telephone line
What reaches them
Desk and user names, work e-mails and telephone numbers, plan and usage counts, and notes and transcripts of calls to us
Location
Region not yet confirmed with Odoo
Datalastic
Purpose
The vessel register, ownership records and AIS positions
What reaches them
Which hull or which sea area was asked for. No customer identity
Location
European Union
Cloudflare
Purpose
DNS for the domain and the www redirect
What reaches them
The name your browser looked up
Location
Global edge network
OpenFreeMap and AWS Terrain Tiles
Purpose
Map tiles, fetched by your browser when a chart is on screen
What reaches them
Your IP address and the tile coordinates. Not who you are
Location
Global edge network

Annex 4: the transfer mechanism

This annex is under review by counsel and is not a completed transfer mechanism. It describes the arrangement we intend. An internal review found that it does not yet settle four things, and they are named here rather than left for your counsel to find: which module of the standard contractual clauses fits, given that Neptune Labs contracts from Canada, which holds an adequacy decision, while the restricted transfer is the onward one to India; whether the clauses are the right instrument at all where the importer is itself subject to the GDPR under Article 3(2); how the clauses flow down to the sub-processors in the United States; and the competent supervisory authority under Clause 13, which is not completed. If you need a completed transfer mechanism for data of people in the EEA or the UK, raise it with us before that data goes into the product.

The transfer. Personal data of data subjects in the EEA and the UK is transferred by you, as controller and exporter, to Neptune Labs in Canada as processor and importer, and is stored on infrastructure in India. Onward transfers go to the sub-processors at Annex 3, in the locations stated there.

The mechanism for the EEA. The European Commission's standard contractual clauses of 4 June 2021, Module Two, controller to processor, incorporated by reference and completed as follows: the optional docking clause applies; Clause 9 option 2, general written authorisation, with the 30 day notice period in the sub-processor clause above; Clause 11's independent dispute resolution option does not apply; Clause 17 is governed by the law of Ireland; Clause 18 gives jurisdiction to the courts of Ireland. Annexes I, II and III to those clauses are Annexes 1, 2 and 3 of this document.

The mechanism for the UK. The Information Commissioner's International Data Transfer Addendum to those clauses, with the tables to be completed from Annexes 1 to 3, the start date being the date your subscription begins, and neither party able to end the addendum under section 19.

Canada. Neptune Labs is a Canadian company and PIPEDA applies to it directly. Canada holds an adequacy decision for commercial organisations, so the transfer to us is not itself the restricted one.

India, which is the restricted transfer. India has no adequacy decision. We have written an internal assessment of the Indian legal framework as it applies to data held by a foreign company on infrastructure there, including the Information Technology Act's interception powers and the Digital Personal Data Protection Act 2023. It is not yet a completed transfer impact assessment, and its conclusion is that supplementary measures are required and are only partly in place. The measures that exist today: encryption in transit, application-level encryption of stored credentials, separation of customers by schema, access to production limited to Neptune Labs staff, and a commitment to challenge any request for data that is not lawfully binding on us and to tell you unless forbidden. Ask at support@neptunelabs.ca and we will tell you where the assessment and the clauses stand.

Government access requests. If a public authority asks for your data, we will tell you unless legally forbidden, and where forbidden we will use reasonable efforts to obtain a waiver. We will challenge a request that is not valid and binding, and we will disclose only the minimum the request compels. To the date at the top of this page, Neptune Labs has received no such request.

Signing this, and getting a copy

A countersigned copy, where the standard contractual clauses and the transfer assessment stand, or a security questionnaire answered: write to support@neptunelabs.ca and say which you need. We answer these ourselves rather than routing them through a form, because there are not yet enough of them to justify a form and a form would let one sit unread.