Sub-processors

Last updated: 2026-07-30 · Version 1.0-draft

1. Introduction

A Sub-processor is a third party that Castawaze LLC ("we", "us", "our") engages to process personal data on our behalf, or that materially supports our delivery of the hosted Opsybots Service, in a manner that involves the processing of personal data. This page is the authoritative, current list of such Sub-processors. It is incorporated by reference into our Privacy Policy and Data Processing Addendum (DPA Annex III and §5), which rely on this page to carry the operative change-notice mechanism described below.

Capitalized terms — Service, Customer Account Metadata, Findings, Sub-processor — carry the meanings given in our Terms of Service and Privacy Policy.

2. Change notice

We will give at least 30 days' notice before adding a new Sub-processor or making a material change to an existing Sub-processor engagement. Notice is given by:

1. Updating this page — the "Last updated" date at the top of this page will reflect each change, and the revision will be published at opsybots.com/legal/subprocessors.
2. Notifying subscribers by email — customers who have subscribed to Sub-processor change notifications will receive an email to the address on record describing the change and the date it takes effect.

To subscribe to Sub-processor change notifications, email privacy@opsybots.com with the subject line "Subscribe: Sub-processor notifications." We will confirm your subscription by return email.

Customers may object to a new or changed Sub-processor on reasonable data-protection grounds within the 30-day notice period, as described in the Data Processing Addendum (/legal/dpa). Where we cannot accommodate an objection and the parties cannot agree on an alternative, the DPA sets out each party's termination rights.

3. Current Sub-processors

Note on Stripe. Stripe processes billing and account-contact data in a context where Castawaze LLC acts as an independent data controller, not as the Customer's processor. Stripe does not process Customer Account Metadata or Findings, and Stripe is not a Sub-processor of Customer Personal Data within the meaning of the Data Processing Addendum or the GDPR.

Note on Postmark. Postmark receives only aggregate DMARC report data — statistical email-authentication summaries that do not contain personal data. It is listed here for transparency. It is not a Sub-processor of personal data within the meaning of the GDPR or UK GDPR.

4. Amazon Bedrock (AI inference)

The Service uses Amazon Bedrock, Amazon Web Services' managed AI inference service, in two distinct places. They differ in the respect that matters most for data protection: whose AWS account the inference runs in.

Agent-side inference, in your account. The scanning agents run inside your own AWS account and call Amazon Bedrock there, using your credentials. This is the call that reviews candidate findings and assigns each one its final severity, polishes its recommendation, and tags it. Nothing leaves your account.

Brief-side inference, in ours. The weekly brief is composed by the hosted dashboard rather than by the agents, so its model call runs on Amazon Bedrock in the Castawaze LLC (Opsybots) AWS account in us-east-1, using our credentials rather than yours. It receives a bounded slice of your data to write prose from: the week's counts, cost totals, posture, and per-pillar status including the names of the agents that ran; your configured organization context; the week's top 25 candidate findings; and, for each pillar's detail section, up to six further findings from that pillar. Those per-pillar findings overlap with the top 25 rather than being wholly additional, so the total is a few dozen distinct findings at most. Each carries its title, recommendation, severity, resource identifiers, estimated monthly cost impact, tags, and internal finding, agent, and pillar identifiers. It does not assign severity; every count, dollar figure, and severity in the brief is computed in code from the stored finding, never by the model.

This is a transit path, not a stored copy. The composed report is written back to your own S3 bucket, and we keep neither the inputs nor the output. It is nonetheless the one place the hosted Service reaches outside your account to do work, and if your requirements put a hard boundary around where processing happens, this is the part to check against them.

Key characteristics of our Amazon Bedrock usage relevant to data protection:

• No retention or training. Amazon Bedrock does not retain prompts or outputs from model invocations, and does not use them to train or improve foundation models. This is a contractual commitment reflected in the AWS Service Terms and the AWS Data Processing Addendum.
• No third-party model API. It is Amazon Bedrock in both cases. No Customer Account Metadata or Findings are transmitted outside AWS to a third-party AI provider, and the Service has no path to any non-AWS model API.
• Infrastructure metadata only. The data reviewed consists solely of AWS infrastructure metadata (resource configurations, IAM settings, cost and usage figures, security posture). Beyond the identifiers described in the Data Processing Addendum, it is not intended to contain personal data, application data, or protected health information (PHI).
• HIPAA-conscious, not HIPAA-compliant. Amazon Bedrock is HIPAA-eligible under AWS's Business Associate Addendum, which is why Opsybots is designed to be HIPAA-conscious. However, Castawaze LLC does not currently offer a Business Associate Agreement (BAA), and Opsybots is not certified or represented as "HIPAA-compliant." Customers must not submit protected health information (PHI) to the Service.

5. Slack (customer-enabled onward transfer)

Slack is not a Sub-processor. It is listed here because it matters, not because it is one.

If an administrator in your Workspace enables Slack delivery (Settings > Notifications), they paste a single Slack incoming-webhook URL that points at your own Slack workspace; we store it encrypted with AWS KMS. We then post the same weekly digest to whichever channel that webhook points at.

Being explicit about the trade: this is the one path where content leaves AWS entirely. The digest's prose, headline figures, and top priorities transit Slack's servers and come to rest in your Slack workspace, under your agreement with Slack and Slack's retention, not ours. We design the digest not to name individual resources: the model that writes it is instructed to keep resource identifiers out of its prose, and we remove identifiers we detect before sending. Treat that as a design intent rather than a guarantee, because a priority's heading can be drawn from the underlying finding, which may name the resource it concerns. What is never sent is the full list of affected resources; to see which bucket or which key, you follow the link into the dashboard.

Because you choose the destination, configure it, and can revoke it at any time by removing the webhook, Slack acts on your instruction rather than as a third party we have engaged to process data on our behalf. We hold no data-processing agreement with Slack covering this content and could not flow our obligations down to it; your own relationship with Slack governs it. Slack delivery is off unless an admin turns it on. If that trade is not one you want to make, leave it off: you lose the digest, not the brief.

6. Contact

Castawaze LLC — Opsybots
Privacy & data requests: privacy@opsybots.com
Legal notices: legal@opsybots.com
Security disclosures: security@opsybots.com
Support & billing: support@opsybots.com