Data Processing Addendum

This addendum forms part of the Terms of Service and applies whenever event data you route through ShellOrbit, or Leak Alarm data we process for you, 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.

Changes in version 1.7. Webhook forwarding has ended. The processing described in Annex I is now receiving security events from the systems you connect, running rules over them, and raising findings and alerts; the categories of data subjects and personal data are updated to match. Resolved findings are deleted after your plan’s history window. This version applies to accounts created from 25 October 2026 at once, and to every other account from 24 November 2026; until then the previous version applies to them.

Changes in version 1.6. From 22 October 2026, Cloudflare (Turnstile) is added to the subprocessor list for bot protection on the sign up, sign in, emailed sign in, and password reset pages and the contact form on shellorbit.com. From 22 October 2026, revoking covers AWS, OpenAI, Anthropic, Google Cloud, Azure, Twilio, SendGrid, and Supabase, through credentials you give us, and you can add a revocation webhook to your own system, which receives a masked value and a match code, never the key. Where you turn it on, a key we find is sent, as data, to its issuer’s own endpoint: GitHub’s and Hugging Face’s token revocation services and Google’s API key lookup. These are your own providers, not our subprocessors. Azure AI services keys are regenerated only after you confirm. Incident Alerts also matches packages you declare against OSV.dev’s public export, which we download whole; nothing about you, not even a package name, is sent to it, and it is not a subprocessor. This version also maps the addendum to India’s Digital Personal Data Protection Act 2023 and the Digital Personal Data Protection Rules 2025 (sections 1, 7, 8, and 10): we act as your Data Processor, help you answer Data Principals, and give you what you need to inform the Data Protection Board of India within 72 hours of a breach.

Changes in version 1.5. From 22 October 2026, you can add your own AI provider to have incidents and findings explained. At your instruction we send that item’s details, with masked values only, to the provider you chose. It is your own vendor, not our subprocessor, and the subprocessor list does not change.

Changes in version 1.4. From 22 October 2026, ShellOrbit no longer scans GitHub repositories, and the Incident Alerts provisions apply. Incident Alerts runs on Amazon Web Services, adds no subprocessor, and sends nothing about you to the public sources it downloads advisories from. This version also sets out which plans and providers revoking covers, states that leaked GitHub tokens are reported to GitHub only where you turn that on, gives the retention of tripwire hit records, and states that sign-in location is recorded only where available.

Changes in version 1.3. From 19 October 2026, all email is sent through Amazon SES and our previous email provider is no longer a subprocessor. The Leak Alarm provisions apply from the same date. Zoho Campaigns and Zoho Desk join the subprocessor list, and Zoho CRM gains a new purpose, from the same date, as set out on the subprocessors page.

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. “Leak Alarm data” means the data we process to provide Leak Alarm on your instructions: findings and their masked values, one way fingerprints of your keys, tripwire hit records, the stack details used by Incident Alerts, and the pages and log lines we scan, which are discarded once scanned. “Stack details” means the products, versions, and labels you declare, the runtime versions, platform, and architecture the SDK reports, and the certificate chain and server header details recorded when a verified domain is scanned. In sections 2 to 14, references to event data include Leak Alarm data unless the context shows otherwise. “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. “DPDPA” means India’s Digital Personal Data Protection Act 2023 and “DPDP Rules” the Digital Personal Data Protection Rules 2025. Where the DPDPA applies, “controller” means Data Fiduciary, “processor” means Data Processor, “data subject” means Data Principal, “personal data breach” carries its DPDPA meaning, and “the Board” means the Data Protection Board of India.

2. Roles and scope

You determine the purposes and means of processing event data. You decide which systems you connect as sources, which events they send and what those events contain, which rules run over them, 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.

For Leak Alarm, your instructions also include the domains you verify, the log drains you configure, the tripwires you plant, the SDK you install, the stack you declare, the keys you allow us to revoke and the providers you connect, whether leaked GitHub and Hugging Face tokens are reported to their issuers, whether Google API keys are looked up with Google, the revocation webhook you add, and the incidents and findings you ask your own AI provider to explain. We scan only what you have verified or connected, never use a key we find as a credential, never test whether it works, never store a key in full, and never act on a key you have not allowed.

When you add your own AI provider and ask for an explanation, we send it the details of that incident or finding, with masked values only and never a secret, at your direction and under your account and that provider’s terms. That provider is your own vendor, not our subprocessor. We store the credentials you give for it encrypted, use them only for these requests, and delete them when you remove them.

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 event 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. That includes the account records we keep in Zoho CRM, product update email sent through Zoho Campaigns, and support tickets held in Zoho Desk. 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 sending events from the systems you connect to us and for their storage on our infrastructure.
• 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.
• For Leak Alarm, you own or are authorised to protect every domain, log source, and system you connect, and you have a lawful basis for the tripwire hit records we collect for you, which can identify people other than your own users, including whoever touches a tripwire.

You control data minimisation in practice: connect only the systems you need, send only the events your rules read, mark fields to mask, choose a shorter history window, and delete sources 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, and, under the DPDPA, for a summary of personal data processed, correction, completion, updating, erasure, nomination, and grievance redressal, in time for you to answer within the period the DPDP Rules allow.

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.

Where the DPDPA applies, our notice and its updates give you what Rule 7 of the DPDP Rules asks you to tell affected Data Principals without delay and the Board within 72 hours, and we will help you prepare both.

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.

Where the DPDPA applies, personal data may be processed outside India, as section 16 of the DPDPA allows, except in a country the Central Government restricts, and we will follow any such restriction.

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. Leak Alarm findings are kept until you resolve them and then for your plan’s retention window. Tripwire hit records are kept for about 13 months (400 days), then deleted automatically. Pages and log lines are discarded as soon as they are scanned. Fingerprints are deleted when you remove the key, the SDK project, or the account. Declared stack items are kept until you remove them, detected stack details are replaced by each newer scan or report, and all stack details are deleted with the account.

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 ShellOrbit’s sources, rules, and findings, and Leak Alarm. Contact for both roles: privacy@shellorbit.com on our side, the account email address on yours.

Subject matter. Receipt, storage, and inspection of security events sent by the systems you connect as sources, the running of ready-made and custom rules over them, and the findings raised from them. Also the detection of exposed keys in the domains and logs you connect, tripwires you plant, the matching of your stack against public security advisories, and the revoking of keys you allow.

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

Nature and purpose. Automated receipt of HTTP requests, signature checking, storage, rule evaluation, raising findings and alerts, display in the dashboard, and metering for billing. For Leak Alarm: automated scanning of verified domains and log drains, with the content discarded once scanned; matching of stack details against public security advisories inside our own infrastructure; recording of tripwire hits; matching of one way fingerprints; on Pro and Business, keeping the hostnames an SDK project’s app connects to and raising a finding for a new one; alerting; on Pro and Business, acting on leaked keys you allow at AWS, OpenAI, Anthropic, Google Cloud, Azure, Twilio, SendGrid, and Supabase (locking open tables), after a ten minute window in which you can cancel, with Azure AI services keys regenerated only after you confirm; sending a revocation request, with a masked value and a keyed match code, to a webhook you add; and, where you turn it on, reporting a leaked GitHub or Hugging Face token to that company’s token revocation service, and looking up a Google API key with Google’s API key lookup; and, on your request, sending an incident’s or finding’s details, with masked values only, to the AI provider you configured.

Categories of data subjects. Whoever appears in the events your sources send. Typically the people with accounts in the systems you connect, such as your staff, contractors, repository contributors, cloud account users, and your app’s end users, and anyone who tries to sign in to those systems. For Leak Alarm, also anyone who touches a tripwire, who may be an attacker, an automated agent, or an unrelated person.

Categories of personal data. Whatever the events contain, which the sending system decides and you choose to connect. Commonly identifiers such as user ids, usernames, email addresses, and names, account activity such as sign ins, failed sign ins, role and setting changes, technical data such as IP addresses, approximate locations, user agents, timestamps, and signature headers, and any free text fields the sender includes. For Leak Alarm: the source IP address and user agent of each tripwire hit; and any personal data that happens to sit next to a key in a page, file, or log line, which is scanned and discarded and is not kept beyond the masked finding.

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 15, 30, 60, or 180 days, plus the deletion windows in section 12. Leak Alarm findings, tripwire hits, and stack details as set out in section 12; scanned content is not retained. AI explanations are kept 7 days.

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. Service credentials, such as payment, authentication, and session signing keys, are held only in AWS Systems Manager Parameter Store, encrypted with a dedicated key and readable only by the functions that need them. They are not kept in source code, in build systems, or in anything sent to a browser.

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. Every plan has an audit log of administrative actions and a sign-in history with IP address, device, and, where available, approximate location, readable for 30 to 365 days depending on the plan and kept for about 13 months.

Tenant separation. Event records are partitioned per account, and every read path is scoped by account identifier. Intake identifiers are unguessable, every source event’s signature is checked before a rule reads it unless you switch the check off for that source, and alert channel URLs are validated to prevent requests into internal address ranges.

Availability and resilience. Managed, replicated storage. Receipt is decoupled from alerting, so a failing alert channel cannot block intake. Point in time recovery for the primary data store, with a rolling backup window that expires within 35 days.

Integrity. Events are stored as received, byte for byte, with the result of their signature check. Changes to a finding’s status are recorded with who made them and when.

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, and separation of log data from payload storage. Credentials and ingest keys are masked before a log line or error report is written. 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. Setup guides that send only the events the rules need, fields you mark masked in the inspector, history windows scaled to the plan, and per source configuration so a sensitive stream can be handled differently from the rest.

Leak Alarm. Scans run only on domains verified with a DNS record, rechecked before every scan; scanned pages and log lines are discarded once scanned; a site’s certificate chain is read from an ordinary TLS handshake and nothing is sent to probe a site for flaws; Incident Alerts matches stack details inside our own infrastructure and sends nothing about you to the sources it downloads advisories from; findings hold a masked value, never a full key; the SDK sends masked values and one way salted fingerprints, never a key; a key we find is never used, not even to test it; revoking happens only for keys you allowed, after a ten minute window in which you can cancel; keys a provider lists are compared in memory and only the provider’s own id is kept; a found key is sent to its issuer’s endpoint (GitHub, Hugging Face, Google’s API key lookup) only where you have turned that on, and never used as a credential; a revocation webhook receives a masked value and a keyed match code, never the key, over https to a public address only; credentials you give us for a connected provider are encrypted with a separate key and used only for the action you allowed; an AI agent connected through the MCP server sees masked values only.

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, Zoho Campaigns, and Zoho Desk sit outside the event path and outside Leak Alarm. They receive account data for which we are the controller, never event data or Leak Alarm data.