> ## Documentation Index
> Fetch the complete documentation index at: https://docs.suprsend.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Shared Responsibility Model

> Guide to ownership boundaries when using SuprSend as a BYOC service

## Purpose and scope

SuprSend BYOC is a shared-responsibility service. SuprSend runs and maintains the application and the resources it provisions, and the client owns its AWS account, its governance and its own security monitoring. This document sets that boundary for new and existing BYOC clients. This is different from selfhosting SuprSend where the user owns everything.

In BYOC, SuprSend runs in the client's AWS account. SuprSend provisions the AWS resources the platform needs (network, Kubernetes cluster, databases, storage) and deploys and operates the application on them.

SuprSend owns resources it provisions and deploys. The client owns the account those resources live in, and anything not listed in this document.

## Responsibility matrix

SuprSend owns the application and every AWS resource it provisions. The client owns the AWS account and everything else.

| Area | What it covers | Owner |
| - | - | - |
| Application | Deployments, updates, patches, application and container security | SuprSend |
| AWS resources provisioned by SuprSend | VPC, EKS, RDS, Valkey, OpenSearch, S3: setup, patches, upgrades, backups, scaling | SuprSend |
| Application IAM roles | Roles and policies SuprSend creates for its own components | SuprSend |
| Application secrets | Credentials for SuprSend's application and datastores | SuprSend |
| Monitoring and incident response | Monitoring, alerting and incident response for SuprSend components; client notified of incidents | SuprSend |
| Audit logs | SuprSend enables audit logging; client retains, reviews and alerts on it | Shared |
| Networking | SuprSend runs the network it provisions; client owns connectivity to its own networks and firewall rules | Shared |
| SuprSend access to the account | Scoped to SuprSend resources; client approves, audits and can revoke it | Shared |
| AWS account and governance | Account, org policies, billing, quotas, client users and roles | Client |
| Account security tooling | GuardDuty, EDR, CSPM, SIEM, compliance scanning | Client |
| Data | Ownership, classification and retention requirements; SuprSend processes data on the client's behalf | Client |
| Anything not listed above | | Client |

### Commitments and limits

* **Kubernetes version:** SuprSend keeps EKS on the latest supported Kubernetes version.
* **Upgrades needing downtime:** SuprSend requests a maintenance window from the client and performs the upgrade.
* **Audit logging:** covers AWS API activity (CloudTrail). Client can create alerts on top of the audit trail if needed.
* **Encryption keys:** data is encrypted with AWS-managed keys.


## Related topics

- [Introduction](https://docs.suprsend.com/docs/self-hosted/introduction.md)
- [Modelling your business customers & applications: tenants vs workspaces](https://docs.suprsend.com/docs/guides/modelling-customers-workspace-vs-tenant.md)
- [Designing Notifications for B2B2C Applications](https://docs.suprsend.com/docs/guides/modelling-customers-b2b2c.md)
- [Designing notifications for multi-tenant B2B applications](https://docs.suprsend.com/docs/guides/modelling-customers-b2b.md)
- [Workspaces](https://docs.suprsend.com/docs/workspaces.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.