Data Processing Addendum

This addendum forms part of the Terms of Service and applies whenever event data you route through ShellOrbit contains personal data. You are the controller. We are the processor. Accepting the terms accepts this addendum, so there is nothing to sign, and a countersigned copy is available on request at privacy@shellorbit.com if your compliance process needs one.

Where this addendum conflicts with the Terms of Service on the processing of personal data, this addendum wins.

1. Definitions

“GDPR” means Regulation (EU) 2016/679, and where the context requires, the UK GDPR as retained in United Kingdom law. “Controller”, “processor”, “personal data”, “processing”, “data subject”, “personal data breach”, and “supervisory authority” carry their GDPR meanings. “Subprocessor” means a processor we engage to process personal data on your behalf. “Event data” means the requests received at your ingest endpoints and the delivery records for them, as described in the Terms of Service. “SCCs” means the Standard Contractual Clauses approved by Commission Implementing Decision (EU) 2021/914. “UK Addendum” means the International Data Transfer Addendum issued by the UK Information Commissioner.

2. Roles and scope

You determine the purposes and means of processing event data. You decide which providers post to your endpoints, what those payloads contain, where events are delivered, how long your plan retains them, and when to delete them.

We process event data only:

• To provide the service as described in the Terms of Service and the documentation.
• On your documented instructions, which include your configuration in the dashboard and your calls to the API.
• As required by law, in which case we will tell you before disclosing anything unless the law forbids that notice.

We will tell you if in our opinion an instruction infringes data protection law. We do not process event data for our own purposes, do not use payload content to train models, and do not sell or share it.

Account data, described in the privacy policy, is data for which we are the controller. This addendum does not apply to it.

3. Your obligations

You confirm that:

• You have a lawful basis for the processing you instruct, including for storage of payloads on our infrastructure and for delivery to the destinations you configure.
• You have given the notices and, where required, obtained the consents that your own data subjects are entitled to.
• Your instructions comply with applicable data protection law.
• You will not route special category data, criminal offence data, payment card numbers, or government identifiers through the service without telling us first at privacy@shellorbit.com, so that both sides can assess whether additional measures are needed.

You control data minimisation in practice: choose a shorter retention plan, use a transformation rule to strip fields before forwarding, and delete events you no longer need.

4. Confidentiality and personnel

Access to event data in production is limited to people who need it to operate the service or to help you with a support request. Those people are bound by confidentiality obligations that survive the end of their engagement, receive security and data protection training, and hold access through individual accounts with multi factor authentication. Administrative access to production data is logged.

5. Security measures

We implement the technical and organisational measures set out in Annex II. Those measures are subject to technical progress, and we may replace a measure with one that is at least as protective. We will not materially reduce the overall level of security during the term.

6. Subprocessors

You give general authorisation for us to engage the subprocessors listed on the subprocessors page, which forms Annex III of this addendum.

• Each subprocessor is bound by a written contract imposing data protection obligations no less protective than this addendum.
• We remain responsible to you for a subprocessor’s performance of those obligations.
• We will give at least 30 days notice before adding or replacing a subprocessor, by email to account holders and by updating the subprocessors page. Subscribe at privacy@shellorbit.com to receive those notices at a different address.
• You may object to a new subprocessor on reasonable data protection grounds within that notice period. If we cannot offer an alternative, you may terminate the affected part of the service and receive a pro rata refund of prepaid fees for the unused remainder of the term, which is an exception to the refund policy.

7. Data subject requests

The dashboard and API let you find, export, and delete events yourself, which is normally the fastest route to answering a request. Where you cannot, we will assist you, at no charge for a reasonable volume of requests, in responding to requests for access, correction, deletion, restriction, objection, or portability.

If a data subject contacts us directly about event data, we will not respond to the substance. We will tell them to contact you, and tell you promptly, unless the law requires otherwise.

8. Personal data breach

If we become aware of a personal data breach affecting event data we will:

• Notify you without undue delay, and in any case within 48 hours of becoming aware, at the account email address.
• Describe the nature of the breach, the categories and approximate volume of data and data subjects affected, the likely consequences, and the measures taken or proposed.
• Provide further information as the investigation develops, and cooperate with your own notification duties to a supervisory authority or to data subjects.
• Take reasonable steps to contain the breach and to prevent a repeat.

Notification is not an admission of fault. You are responsible for deciding whether to notify a supervisory authority or your data subjects, since you hold the context that determines risk.

9. Impact assessments and audits

On request, we will give you the information reasonably needed for a data protection impact assessment or a consultation with a supervisory authority, including the contents of this addendum, the subprocessor list, and available third party audit reports of our infrastructure providers.

You may audit our compliance with this addendum, no more than once in any 12 month period unless a breach or a regulator requires otherwise, by sending a reasonable questionnaire or by requesting the documentation described above. On site inspection of the underlying infrastructure is not possible, because the infrastructure is operated by Amazon Web Services and covered by its own certification and audit programme, whose reports we will pass through where our agreement permits. You bear your own costs, and we may charge for time spent beyond a reasonable level of assistance.

10. International transfers

Where processing of personal data under this addendum involves a transfer out of the European Economic Area, the United Kingdom, or Switzerland to a country without an adequacy decision:

• The SCCs are incorporated into this addendum, with Module Two applying between you as controller and us as processor, and Module Three where you act as a processor for another controller.
• For Clause 7, the docking clause applies. For Clause 9, option 2 applies, with the 30 day notice period in section 6. For Clause 11, the optional independent dispute resolution language does not apply. For Clause 17, the governing law is the law of the EU member state where the data exporter is established. For Clause 18, the forum is the courts of that member state.
• Annexes I, II, and III of the SCCs are populated by the Annexes below, together with the subprocessors page.
• For UK transfers, the UK Addendum is incorporated, with the SCCs completed as above and the start date being the effective date of this addendum.
• For Swiss transfers, references to the GDPR are read as references to the Swiss Federal Act on Data Protection, and the Swiss Federal Data Protection and Information Commissioner is the competent authority.

11. United States state privacy law

Where the California Consumer Privacy Act as amended applies, we act as a service provider. We do not sell or share personal information, do not retain, use, or disclose it except to provide the service or as permitted by the CCPA, do not combine it with personal information from other sources except as the CCPA allows, and will notify you if we determine we can no longer meet those obligations. Equivalent commitments apply where a comparable state law treats us as a processor or service provider.

12. Deletion and return

You can delete event data at any time through the dashboard or the API. Events also delete automatically at the end of your plan’s retention window.

On termination, we retain stored event data for 30 days so you can export it, then delete it from live systems. Backup copies expire within a further 35 days. We will confirm deletion in writing on request.

Two things outlive that, and both are named rather than left to the general clause. Request and access logs are kept for 365 days because the CERT-In Directions require a rolling 180 days and require us to produce them on demand; they record that a request reached an endpoint at a time, and hold no payload body. We also keep the date of an account deletion alongside a one way hash of the email address, which cannot be reversed into an address and exists only so a deletion can be evidenced without keeping the person’s details to evidence it. Section 8(7) of the Digital Personal Data Protection Act 2023 permits retention where another law compels it, and this addendum continues to apply to both copies.

13. Liability

Liability under this addendum is subject to the limitation of liability in the Terms of Service, except where applicable data protection law does not permit that limitation. Nothing in this addendum limits a data subject’s rights against either of us under the SCCs.

14. Term

This addendum applies for as long as we process event data for you, and its confidentiality, security, deletion, and transfer provisions survive until deletion is complete.

Annex I: description of processing

Parties. Data exporter: you, the customer, acting as controller, or as processor where you route data on behalf of another controller. Data importer: ShellOrbit, acting as processor, providing the ShellOrbit webhook receiving and delivery service. Contact for both roles: privacy@shellorbit.com on our side, the account email address on yours.

Subject matter. Receipt, durable storage, inspection, transformation where configured, and delivery of webhook events, together with records of each delivery attempt.

Duration. The term of your subscription, plus the deletion windows in section 12.

Nature and purpose. Automated receipt of HTTP requests, storage, queued delivery with retry and backoff, replay on your instruction, display in the dashboard, alerting on failure, and metering for billing.

Categories of data subjects. Whoever appears in the payloads your providers send. Typically your end users and customers, and the individuals identified in the systems that emit those webhooks, such as payers, buyers, subscribers, repository contributors, or account holders.

Categories of personal data. Whatever the payload contains, which we neither select nor control. Commonly identifiers such as user ids, email addresses, and names, transaction details such as amounts, currencies, order references, and subscription state, technical data such as IP addresses, user agents, timestamps, and signature headers, and any free text fields the provider includes.

Special category data. Not expected, and not permitted without prior notice to us under section 3. Where you have told us and we have agreed, additional measures are recorded in writing between us.

Frequency. Continuous, for as long as your providers send events.

Retention. Your plan’s retention window, being 3, 14, 30, or 90 days, plus the deletion windows in section 12.

Processing by subprocessors. As described on the subprocessors page, for the duration and purposes stated there.

Annex II: technical and organisational measures

Encryption. TLS 1.2 or higher for all ingest, dashboard, and API traffic. Encryption at rest for event storage, object storage, queues, and backups using managed keys. Signing secrets and API keys held in a managed secret store.

Access control. Individual named accounts with multi factor authentication for production access. Least privilege roles, reviewed periodically. No shared credentials. Administrative access to production data is logged with actor and timestamp, and the log is available to Business plan customers as an audit log.

Tenant separation. Event records are partitioned per account, and every read path is scoped by account identifier. Ingest identifiers are unguessable, and destination URLs are validated to prevent delivery into internal address ranges.

Availability and resilience. Managed, replicated storage. Receipt is decoupled from delivery through a queue, so a failing destination cannot block ingest. A dead letter queue preserves events whose delivery attempts are exhausted. Point in time recovery for the primary data store, with a rolling backup window that expires within 35 days.

Integrity. Payloads are stored as received, byte for byte, and replays send the original bytes. Delivery attempts are recorded with status code, timing, and response excerpt.

Vulnerability management. Automated dependency and platform patching, alerting on error rate and failed jobs, and a published contact for vulnerability reports at security@shellorbit.com.

Logging and monitoring. Application and access logs kept for 365 days, which clears the rolling 180 day floor the CERT-In Directions of April 2022 place on every service provider and body corporate in India. These logs record which endpoint received a request and when, and are held separately from payload storage so they are not a second copy of the data with a different lifetime. Alarms on anomalous error rates and on billing anomalies, alarms on anomalous error rates and on billing anomalies, and separation of log data from payload storage. Error reports sent to the monitoring subprocessor are scrubbed of request and response bodies and of authorization, cookie, and signature headers before they leave our systems, so diagnostic data does not become a second copy of payload data with different retention.

Personnel. Confidentiality obligations, security and data protection training, and removal of access on role change or departure.

Deletion. Automatic expiry of events at the end of the plan retention window, immediate deletion from live systems on request, and expiry from backups within 35 days.

Data minimisation support. Transformation rules that strip or reshape payload fields before forwarding, plan retention windows as short as 3 days, and per endpoint configuration so a sensitive stream can be handled differently from the rest.

Subprocessor management. Written agreements with data protection terms, a published subprocessor list, and 30 days notice before a change.

Annex III: subprocessors

These are the subprocessors engaged at the effective date, each with its purpose, the categories of data it processes, and its role. The subprocessors page carries the same list and is kept current between revisions of this addendum; where the two differ, the subprocessors page is the operative list and this table records the position at the effective date above.

Sentry may receive personal data incidentally, inside a diagnostic record rather than as a payload. Request and response bodies are stripped and sensitive headers removed before any report is sent, so what leaves our systems is the shape of a failure: the exception, the code path, the endpoint id, the event id, and the account id. Sentry is bound by its own data processing terms, and error reports are deleted after 90 days.

Zoho CRM sits outside the delivery path. It never receives event data, and an enquiry reaches it only when a person chooses to use the contact form rather than write to one of the published addresses.