Data Processing Agreement

• ▸Personal data means any information relating to an identified or identifiable person. An email address, the contents of an email, a name, or an IP address can all be personal data.
• ▸Processing means anything done with personal data, including collecting, storing, analysing, sharing, and deleting it.
• ▸Controller means the party that decides why and how personal data is processed.
• ▸Processor means a party that processes personal data on the controller's instructions and does not decide the purpose for itself.
• ▸Sub-processor means a third party a processor engages to help carry out the processing.
• ▸Data subject means the person the personal data is about.
• ▸Personal data breach means a security incident that leads to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.
• ▸Data protection law means the privacy and data protection laws that apply to the processing, which may include the UK and EU GDPR, Canadian PIPEDA, and applicable state privacy laws.

Our role changes depending on which product is in use. This matters because the obligations differ.

• ▸Consumer apps and extension. When an individual signs up directly for our apps, browser extension, or web dashboard, Ṣọ is the controller of their personal data. Our Privacy Policy governs that relationship, not this DPA.
• ▸Ṣọ Shield API. The Customer is the controller of the content it submits. Ṣọ is the processor and processes that content only to return a result and to run the service.
• ▸Enterprise deployments. The organisation is the controller of its employees' data. Ṣọ is the processor.
• ▸Partner and MSP arrangements. Where a partner deploys Ṣọ for its own clients, the partner or its client is the controller. Ṣọ is the processor, or a sub-processor where the partner is itself acting as processor for its client. The signed agreement must record which of these applies.

Automated email threat detection and related security analysis. In practice this means:

• ▸Analysing messages and headers for phishing, spoofing, and business email compromise signals.
• ▸Checking sender authentication records (SPF, DKIM, DMARC).
• ▸Analysing URLs, domains, QR codes, attachments, and documents for risk.
• ▸Checking an email address against known breach data, where the Customer enables that feature.
• ▸Returning a score, verdict, or explanation to the Customer, and keeping usage records for billing, abuse prevention, and support.

We do not use Customer content to train general models or for advertising.

• ▸Documented instructions only. We process personal data only to provide the services and only on the Customer's documented instructions, which include the agreement, this DPA, and the Customer's use of product settings. If we believe an instruction breaks data protection law, we will tell the Customer.
• ▸Confidentiality. Access is limited to staff and contractors who need it to do their job. They are bound by confidentiality obligations that survive the end of their engagement.
• ▸Security measures. We keep appropriate technical and organisational measures in place, taking account of the risk. These include encryption in transit, encryption at rest for stored records, access control, logging, and analysing submitted content in memory rather than storing it. See Section 09.
• ▸Help with data subject requests. We will help the Customer respond to access, correction, deletion, restriction, portability, and objection requests. Because we do not store submitted content, in most cases the Customer holds the data itself. We will pass any request we receive directly to the Customer rather than answering it ourselves.
• ▸Breach notification. We will notify the Customer without undue delay after becoming aware of a personal data breach affecting the Customer's data, and we will include the information the Customer reasonably needs to meet its own reporting duties. The signed version should state a firm outer limit for that notice, for example 48 or 72 hours.
• ▸Help with assessments. We will provide reasonable help with data protection impact assessments and prior consultations with regulators, so far as they relate to our processing.
• ▸Deletion or return. On termination, and on the Customer's written request, we will delete or return personal data we hold, except where law requires us to keep it. Billing records are kept for the statutory period.
• ▸Audits. We will make available the information reasonably needed to show we meet this DPA, and we will allow audits or inspections by the Customer or an independent auditor it appoints. Audits should be on reasonable notice, no more than once a year unless a regulator requires more or a breach has occurred, and subject to confidentiality. Where available, a current third-party report or certification may be provided instead.
• ▸Government and law enforcement requests. If we receive a legally binding request for the Customer's data, we will tell the Customer unless the law forbids it, and we will challenge requests that appear unlawful or overbroad.

• ▸The Customer confirms it has a lawful basis for the processing it instructs, and that it has given any notices and obtained any consents required, including for content belonging to its own end users.
• ▸The Customer is responsible for the accuracy of the data it submits and for its own configuration choices, including what it blocks, quarantines, or allows on the basis of our output.
• ▸Where meeting features or recording are used, the Customer is responsible for participant notice and consent under the laws that apply to each participant.

The Customer gives general authorisation for us to engage the sub-processors below. Each is bound by data protection obligations no less protective than those in this DPA, and we remain responsible for their performance. We will give the Customer reasonable notice before adding or replacing a sub-processor, and the Customer may object on reasonable data protection grounds.

• ▸Amazon Web Services. Cloud hosting, compute, storage, and database infrastructure for the platform and the API.
• ▸Stripe. Subscription payments, invoicing, and billing records. Card details go to Stripe and are not stored by us.
• ▸Have I Been Pwned. Checking an email address against known breach data. Only the email address is sent. No passwords and no message content are sent.
• ▸Google. Sign-in with Google, and Gmail API access to read and act on mail where the user connects a Gmail account.
• ▸Microsoft. Sign-in with Microsoft, and Microsoft Graph access to Outlook mailboxes where the user connects an Outlook or Microsoft 365 account.
• ▸Apple. Sign in with Apple, and push notification delivery to iOS devices.
• ▸SMTP email delivery provider. Sending transactional and security alert email, such as breach alerts, verification messages, and billing notices. The provider will be named in the signed version.
• ▸Wise. Paying out referral rewards and similar payments to recipients who provide bank details for that purpose.
• ▸Ṣọ machine learning classification service. Our own hosted classification service, which scores messages, headers, links, and documents for risk. It runs on our infrastructure and is listed here for completeness.

• ▸We are based in Canada and our infrastructure and sub-processors operate in more than one country, so personal data may be transferred across borders.
• ▸Where data protection law requires a transfer mechanism, the parties intend to rely on an appropriate one, such as the European Commission's standard contractual clauses, the UK international data transfer addendum, or a valid adequacy decision.
• ▸Which mechanism applies, which modules and annexes are used, and whether a transfer impact assessment is needed must be confirmed by counsel before signing. Nothing in this draft should be read as confirming that a valid mechanism is already in place.
• ▸Customers who need data to stay in a specific region should raise it before signing, as regional hosting is not available on all plans.

Our current security measures are described in our Privacy Policy. The signed version of this DPA should attach them as an annex.

• ▸This DPA takes effect on the date both parties sign it and continues for as long as we process personal data on the Customer's behalf.
• ▸Where this DPA and the main agreement conflict on data protection, this DPA applies to that point.
• ▸The liability provisions of the main agreement apply to this DPA. How liability is allocated for data protection claims, and whether any cap applies, must be settled by counsel before signing.