Data processing addendum
Effective date: the date the Customer accepts the Spendsaw terms of service, or [DPA EFFECTIVE DATE] if signed separately.
This Data Processing Addendum (the "DPA") forms part of the Spendsaw terms of service (the "Terms") between [LEGAL ENTITY NAME], a [ENTITY TYPE] formed in [STATE OF FORMATION], of [REGISTERED ADDRESS] ("Spendsaw"), and the customer that accepted the Terms ("Customer"). Spendsaw is a 45Squared venture.
1. Definitions
Words defined in the Terms have the same meaning here. In addition:
"Customer Personal Data" means personal data contained in Customer Data that Spendsaw processes on Customer's behalf to provide the Hosted Service. Annex I describes it.
"Data Protection Law" means the laws on privacy and personal data that apply to the processing of Customer Personal Data, including, where they apply, the GDPR, the UK GDPR and the CCPA.
"GDPR" means Regulation (EU) 2016/679. "UK GDPR" means the GDPR as it forms part of the law of the United Kingdom, together with the Data Protection Act 2018.
"CCPA" means the California Consumer Privacy Act of 2018 as amended by the California Privacy Rights Act of 2020, and its regulations.
"EU SCCs" means the standard contractual clauses annexed to Commission Implementing Decision (EU) 2021/914 of 4 June 2021.
"UK Addendum" means the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses issued by the UK Information Commissioner, as revised from time to time.
"Security Incident" means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data in Spendsaw's possession or control.
"Sub-processor" means another processor that Spendsaw engages to process Customer Personal Data.
"controller", "processor", "data subject", "personal data", "processing" and "supervisory authority" have the meanings given in the GDPR. "business", "service provider", "sell" and "share" have the meanings given in the CCPA.
2. Scope and roles
2.1 Scope. This DPA applies to Spendsaw's processing of Customer Personal Data. It does not apply to personal data for which Spendsaw is a controller, such as Customer's account, sign-in and billing details. The Spendsaw privacy policy describes that data.
2.2 Customer as controller. Where Customer decides the purposes and means of processing Customer Personal Data, Customer is the controller and Spendsaw is its processor. Under the CCPA, Customer is the business and Spendsaw is its service provider.
2.3 Customer as processor (managed service providers). Where Customer processes Customer Personal Data on behalf of someone else, for example a managed service provider that connects its clients' AWS accounts, Customer is a processor for its client and Spendsaw is Customer's sub-processor. In that case:
- (a) Customer confirms that its client has authorised it to engage Spendsaw, and Spendsaw's Sub-processors, on the terms of this DPA;
- (b) Customer's instructions to Spendsaw are treated as the instructions of the client, and Customer is responsible for passing them on accurately;
- (c) Spendsaw will deal with Customer and not with the client, unless the law requires otherwise;
- (d) where this DPA requires Spendsaw to notify or assist "Customer", Spendsaw does so to Customer, and Customer is responsible for informing its client.
2.4 Approver records. The action record stores the identity of the person who approved each change. Spendsaw keeps that record both as part of the service to Customer and as its own evidence of the instruction it was given. [APPROVER RECORD ROLE: counsel to confirm whether Spendsaw is processor, controller or both for approver identities. The privacy policy currently lists them as controller data and Annex I lists them here.]
3. Details of the processing
3.1 Subject matter. Providing the Hosted Service: scanning Customer's connected AWS accounts for cost waste, explaining and ranking what is found, running changes Customer approves, opening pull requests, and reporting.
3.2 Duration. The term of the Terms, and afterwards until Customer Personal Data is deleted under section 10.
3.3 Nature and purpose. Collection, storage, analysis, display and transmission of AWS resource metadata, metrics and cost data, for the purpose in section 3.1.
3.4 Types of data and data subjects. Annex I.
4. Customer's instructions
4.1 Documented instructions. Spendsaw will process Customer Personal Data only on Customer's documented instructions, including for transfers to another country, unless the law that applies to Spendsaw requires otherwise. In that case Spendsaw will tell Customer before processing, unless that law forbids it.
4.2 What the instructions are. Customer's instructions are: (a) the Terms and this DPA, (b) the configuration Customer chooses, including which accounts to connect, which Roles to deploy, which integrations to install and who may approve, and (c) each Approval. Customer may give further written instructions that are consistent with the Terms.
4.3 Unlawful instructions. Spendsaw will tell Customer if, in its opinion, an instruction breaks Data Protection Law. Spendsaw is not required to follow that instruction until the parties have resolved the point.
4.4 Customer's responsibilities. Customer is responsible for: (a) having a lawful basis for the processing and for any notices owed to data subjects, (b) the accuracy and lawfulness of Customer Personal Data, and (c) not placing special categories of personal data, or personal data about criminal convictions, in AWS resource names, tags or descriptions.
5. CCPA terms
Where the CCPA applies to Customer Personal Data, Spendsaw:
- (a) will process it only for the business purposes in section 3.1 and Annex I;
- (b) will not sell or share it;
- (c) will not keep, use or disclose it for any purpose other than those business purposes, including for its own commercial purposes, or outside the direct business relationship between Spendsaw and Customer, except as the CCPA allows a service provider to do;
- (d) will not combine it with personal information it receives from another source or collects from its own dealings with a person, except as the CCPA allows a service provider to do;
- (e) will comply with the CCPA obligations that apply to it and give Customer Personal Data the level of privacy protection the CCPA requires;
- (f) will tell Customer if it decides it can no longer meet its obligations under the CCPA;
- (g) accepts that Customer may take reasonable and appropriate steps to check that Spendsaw uses Customer Personal Data consistently with Customer's CCPA obligations, through the audit rights in section 11, and to stop and remedy unauthorised use.
Spendsaw certifies that it understands these restrictions and will comply with them.
6. Confidentiality
Spendsaw will make sure that everyone it authorises to process Customer Personal Data is bound by a duty of confidentiality, by contract or by law.
7. Security
7.1 Measures. Spendsaw will implement and maintain the technical and organisational measures in Annex II. Taking into account the state of the art, cost, and the nature, scope and purposes of the processing, the parties consider those measures appropriate to the risk at the date of this DPA, subject to the status notes in Annex II.
7.2 Changes. Spendsaw may change the measures as long as the change does not materially reduce the overall protection of Customer Personal Data.
7.3 Customer's part. Customer is responsible for the security of its own AWS accounts, Roles, ExternalId, Slack workspace, repositories, sign-in credentials and API credentials, and for deciding whether the measures in Annex II meet its needs.
8. Sub-processors
8.1 General authorisation. Customer gives Spendsaw general written authorisation to engage Sub-processors. The Sub-processors at the date of this DPA are listed in Annex III.
8.2 New Sub-processors. Spendsaw will give Customer at least [SUB-PROCESSOR NOTICE DAYS] days' notice before adding or replacing a Sub-processor, by email to the account's contact address or by updating a published list that Customer can subscribe to.
8.3 Objection. Customer may object on reasonable data protection grounds within the notice period. The parties will discuss the objection in good faith. If it is not resolved, Customer may end the affected part of the Hosted Service by written notice, and Spendsaw will refund fees paid in advance for the period after termination. That is Customer's only remedy for the objection.
8.4 Terms with Sub-processors. Spendsaw will have a written contract with each Sub-processor that imposes data protection obligations no less protective than this DPA. Spendsaw remains responsible to Customer for each Sub-processor's performance.
8.5 Integrations Customer installs. Slack and GitHub receive Customer Data only if Customer installs the Slack app or the GitHub App, in the workspace, channel and repositories Customer chooses, and under Customer's own agreement with each of them. [INTEGRATION STATUS: counsel to confirm whether Slack and GitHub are Sub-processors of Spendsaw or recipients that Customer instructs Spendsaw to send data to. Annex III lists them either way.]
9. Helping Customer
9.1 Data subject requests. If a data subject sends Spendsaw a request about Customer Personal Data, Spendsaw will pass it to Customer without undue delay and will not answer it itself, except to say that it has been passed on. Taking into account the nature of the processing, Spendsaw will give Customer reasonable help, by appropriate technical and organisational measures, to respond to requests to exercise data subject rights.
9.2 Impact assessments and consultation. Spendsaw will give Customer reasonable help with data protection impact assessments and prior consultation with a supervisory authority, to the extent they relate to the Hosted Service and Customer cannot get the information another way.
9.3 Security Incidents. Spendsaw will notify Customer without undue delay, and in any event within [BREACH NOTIFICATION HOURS: 48 | 72] hours, after becoming aware of a Security Incident. The notice will describe, as far as Spendsaw then knows: the nature of the incident, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed. Spendsaw will send further information as it becomes available, will take reasonable steps to contain and investigate the incident, and will give Customer reasonable help with Customer's own notification duties. A notice under this section is not an admission of fault.
9.4 Cost. Spendsaw may charge its reasonable costs for help under sections 9.1 and 9.2 that goes beyond the ordinary features of the Hosted Service, if it tells Customer first.
10. Deletion and return
10.1 During the term. Customer can remove data from the Hosted Service by disconnecting an account or deleting the Roles. Findings for a resource are deleted when a later successful scan of its account and region no longer sees it.
10.2 At the end. When the Hosted Service ends for Customer, Spendsaw will, at Customer's choice, return Customer Personal Data in a common machine-readable format or delete it, and will delete remaining copies within [DATA DELETION DAYS] days, unless the law that applies to Spendsaw requires it to keep the data. Copies in backups are overwritten on the normal backup cycle and are protected by this DPA until then.
10.3 Confirmation. On request, Spendsaw will confirm in writing that deletion is complete.
11. Information and audits
11.1 Information. Spendsaw will make available to Customer the information reasonably needed to show that it meets its obligations under this DPA. At the date of this DPA that is the trust page, the Documentation, the Role templates and Spendsaw's written answers to reasonable security questions. Spendsaw has no SOC 2 report, no other certification and no third-party penetration test report to provide.
11.2 Audits. If the information under section 11.1 is not enough for Customer to meet its duties under Data Protection Law, or a supervisory authority requires it, Customer may audit Spendsaw's compliance with this DPA, itself or through an independent auditor bound by confidentiality, on these conditions:
- (a) at least
[AUDIT NOTICE DAYS]days' written notice, except where a supervisory authority requires less; - (b) no more than once in any 12 months, except after a Security Incident or where a supervisory authority requires it;
- (c) during business hours, with a scope agreed in advance, and without access to other customers' data or to information that would put the security of the Hosted Service at risk;
- (d) at Customer's cost, unless the audit finds a material breach of this DPA by Spendsaw.
11.3 Roles as evidence. Customer can verify at any time what Spendsaw is able to do in a connected AWS account by reading the IAM policies on the Roles in that account and the account's own AWS CloudTrail records of Spendsaw's sessions.
12. International transfers
12.1 Location. Spendsaw processes Customer Personal Data in [HOSTING REGION: not yet defined. The default in the code is us-east-1, United States.] and in the locations of its Sub-processors in Annex III. Spendsaw makes no data residency commitment.
12.2 Transfers from the EEA. Where Customer transfers Customer Personal Data that is subject to the GDPR to Spendsaw in a country that the European Commission has not found to give adequate protection, the EU SCCs are incorporated into this DPA by reference and apply as follows:
- (a) Module Two (controller to processor) applies where Customer is a controller. Module Three (processor to processor) applies where Customer is a processor, as described in section 2.3.
- (b) Customer is the data exporter and Spendsaw is the data importer.
- (c) Clause 7 (docking clause):
[applies | does not apply]. - (d) Clause 9 (sub-processors): Option 2, general written authorisation, with the notice period in section 8.2.
- (e) Clause 11 (redress): the optional language does not apply.
- (f) Clause 17 (governing law): the law of
[EU MEMBER STATE FOR SCC GOVERNING LAW]. - (g) Clause 18 (forum): the courts of
[EU MEMBER STATE FOR SCC FORUM]. - (h) Annex I of the EU SCCs is completed with Annex I of this DPA. Annex II is completed with Annex II of this DPA. Annex III is completed with Annex III of this DPA.
- (i) The competent supervisory authority is the one identified under Clause 13 for the data exporter:
[COMPETENT SUPERVISORY AUTHORITY].
12.3 Transfers from the United Kingdom. Where the transfer is subject to the UK GDPR, the UK Addendum is incorporated into this DPA by reference and applies to the EU SCCs as completed in section 12.2. Table 1 of the UK Addendum is completed with the parties' details in Annex I. Tables 2 and 3 are completed with the selections in section 12.2 and Annexes I to III. For Table 4, [UK ADDENDUM TABLE 4: which party may end the addendum: importer | exporter | neither].
12.4 Transfers from Switzerland. [SWISS TRANSFERS: counsel to add the adaptations to the EU SCCs required for transfers subject to the Swiss Federal Act on Data Protection, if Spendsaw will accept Swiss customers.]
12.5 Onward transfers. Spendsaw will not transfer Customer Personal Data onward to a Sub-processor in a country without an adequacy decision unless a valid transfer mechanism under Data Protection Law is in place.
12.6 Conflict. If this DPA conflicts with the EU SCCs or the UK Addendum, the EU SCCs or the UK Addendum control.
12.7 Transfer impact assessment and government requests. [TRANSFER IMPACT ASSESSMENT: counsel to advise whether Spendsaw should prepare one and what supplementary measures to list.] If Spendsaw receives a legally binding request from a public authority for Customer Personal Data, it will tell Customer before responding unless the law forbids it, and will disclose only what the law requires.
13. Liability
Each party's liability under this DPA is subject to the limits in section 14 of the Terms. Nothing in this DPA limits a data subject's rights under the EU SCCs or the UK Addendum, or a party's liability to a data subject or a supervisory authority where Data Protection Law does not allow it to be limited.
14. General
14.1 Term. This DPA lasts as long as Spendsaw processes Customer Personal Data.
14.2 Precedence. If this DPA conflicts with the Terms on a data protection matter, this DPA controls.
14.3 Changes. Spendsaw may update this DPA where a change in Data Protection Law requires it, or to add a Sub-processor under section 8, by giving notice. Other changes need both parties' agreement.
14.4 Governing law. This DPA is governed by the law that governs the Terms, except where the EU SCCs or the UK Addendum say otherwise.
14.5 Contact. Data protection notices to Spendsaw: [privacy@spendsaw.com]. Security Incident notices to Customer go to the email address on Customer's account. Customer must keep it current.
Annex I. Details of the processing
A. Parties
Data exporter. Customer, as named on its Spendsaw account or Order. Contact: the email address on the account. Role: controller, or processor where section 2.3 applies.
Data importer. [LEGAL ENTITY NAME], [REGISTERED ADDRESS]. Contact: [privacy@spendsaw.com]. Role: processor, or sub-processor where section 2.3 applies.
B. Description of the transfer and the processing
Categories of data subjects.
- Customer's staff and contractors who work in the connected AWS accounts.
- Where Customer is a managed service provider, the staff and contractors of its clients.
- People authorised by Customer to approve changes.
- Any other person whose name or contact detail Customer's team has put in an AWS resource name, tag or description.
Categories of personal data. The Hosted Service is built to collect infrastructure metadata, not information about people. The personal data in it is incidental and small:
- AWS account names, where an account is named after a person.
- Root email addresses of AWS accounts, which AWS returns when the Hosted Service lists the accounts in an organisation.
[ACCOUNT EMAIL HANDLING: to match the final wording of section 4.1 of the privacy policy. Draft position: received in AWS's response and discarded, not stored.] - Names, email addresses or usernames that appear in resource names, tags and short descriptions.
- IAM principal names and ARNs, including IAM user names, role names and role session names, taken from CloudTrail records of calls to Amazon Bedrock.
- Identities of people who request, approve, reject, snooze or run a change: Slack workspace id, Slack user id and Slack username, or the email address, username or user id from the sign-in token, with the time and the commands approved.
- Questions typed into the console chat, to the extent a person puts personal data in them.
Data the Hosted Service does not collect. The contents of S3 objects, DynamoDB items, secret values, parameter values, log events, Lambda code, queue messages, stream records, container images and repository contents. The read-only Role denies those reads in IAM. The single exception is the opt-in reading of Terraform state files, from which only resource addresses, types, names, modules, indexes, providers, ids and ARNs are kept.
Special categories of data. None intended. Customer must not place any in resource names, tags or descriptions (section 4.4).
Frequency of the transfer. Continuous while an account is connected: on each scheduled scan, and when a user asks for a scan, a report or an answer in the console.
Nature of the processing. Collection through AWS APIs under the Roles; storage; analysis by fixed rules; ranking and explanation by a model on Amazon Bedrock; display in the console, API, Slack messages, pull requests and reports; execution of approved changes.
Purpose. Providing the Hosted Service to Customer.
Retention. As stated in the "Data retention" section of the trust page and section 8 of the privacy policy. Periods not yet defined: [RETENTION: APPROVAL AND ACTION RECORDS], [RETENTION: SAVINGS LEDGER], [DELETION ON OFFBOARDING], [RETENTION: BEDROCK INVOCATION LOGS].
Sub-processors. Annex III, for the same subject matter, nature and duration.
C. Competent supervisory authority
[COMPETENT SUPERVISORY AUTHORITY]
Annex II. Technical and organisational measures
Each measure names the file it comes from. Status says how far it has been proven:
- In code means the measure is implemented in application code or in a template the customer deploys, and has automated tests that run against simulated AWS, Slack or GitHub services.
- Designed means the measure is defined in the hosted infrastructure code, which has been validated offline and has not yet been applied to an AWS account.
At the date of this draft, no measure has been validated against live AWS.
1. Access to customer AWS accounts
| Measure | Status | Source |
|---|---|---|
| Access only through IAM roles the customer deploys from published templates. No long-lived access keys for customer accounts. | In code | cloudformation/cost-agent-readonly.yaml, aws/account_manager.py |
| Each role trusts one AWS account and requires a per-tenant ExternalId, passed on every assume-role call. | In code | cloudformation/*.yaml, aws/account_manager.py |
| ExternalId is 16 random bytes per tenant, stored in AWS Secrets Manager. | Designed | infra/terraform/modules/tenant/main.tf |
| Explicit IAM deny on data-plane reads (S3 objects, table items, secrets, parameters, log events, function code and others). | In code | cloudformation/cost-agent-readonly.yaml |
Separate, opt-in write role limited to the low and medium risk actions, with an IAM deny on resources tagged Keep=true. Not created or used in the management account. |
In code | cloudformation/cost-agent-remediator.yaml, remediation/approvals.py, aws/account_manager.py |
| Sessions capped at 3600 seconds. 900 seconds requested for the write role. | In code | cloudformation/*.yaml, aws/account_manager.py |
Terraform state is read only through a separate opt-in role limited to .tfstate objects in one named bucket. The parser keeps identifiers and discards all other attributes. |
In code | cloudformation/cost-agent-state-reader.yaml, iac/state.py |
2. Separation between customers
| Measure | Status | Source |
|---|---|---|
| Every customer table has the tenant id as its partition key. | Designed | infra/terraform/modules/tables/main.tf |
| Each worker invocation serves one tenant, in a session whose IAM policy allows item access only where the leading key equals the session's tenant id. Table scans are not granted. | Designed | infra/terraform/modules/tenant_session_role/main.tf, workers/common.py |
| The tenant is taken from the verified sign-in token, never from the request. | In code | workers/api.py |
| Cross-account sessions are cached per tenant, and a new model agent is built for each request and bound to one tenant. | In code | aws/account_manager.py, ai/bedrock_client.py |
| Known limit: a worker chooses its tenant tag from its event, so a compromised worker could open a session for any tenant. | Open | infra/README.md |
3. Encryption
| Measure | Status | Source |
|---|---|---|
| Server-side encryption at rest on the database tables. | Designed | infra/terraform/modules/tables/main.tf |
| Server-side encryption on the failed-scan queue. | Designed | infra/terraform/modules/scanner/main.tf |
| Server-side encryption on the bucket that holds the role templates, with a deny on unencrypted transport. | Designed | infra/terraform/modules/onboarding/main.tf |
| Calls to AWS, Stripe, Slack and GitHub APIs are made over HTTPS. | In code | billing/stripe_client.py, delivery/slack/client.py, iac/github_app.py |
| Key management (AWS-owned or customer-managed keys) and TLS configuration for the hosted API and console. | [NOT YET DEFINED] |
docs/soc2-readiness.md |
4. Authentication and authorisation
| Measure | Status | Source |
|---|---|---|
| Hosted sign-in through Amazon Cognito: invite-only accounts, minimum password length 14, optional one-time-code multi-factor authentication, 60-minute access tokens, token revocation. | Designed | infra/terraform/modules/api/main.tf |
| API requests authorised by a JWT authoriser with separate read and approval scopes. Request throttling on the API. | Designed | infra/terraform/modules/api/main.tf |
| Approving or executing a change always requires an identified caller, whatever the authentication mode. | In code | security/auth.py, app.py |
| In Slack, only user ids on the customer's approver list can approve. An empty list means nobody can. | In code | delivery/slack/interactions.py, delivery/slack/config.py |
| Requests from Slack and Stripe are accepted only with a valid signature and a recent timestamp. | In code | delivery/slack/interactions.py, billing/stripe_routes.py |
| The application refuses to start without a session signing key of at least 16 characters. | In code | app.py |
| Multi-factor authentication required for all users; single sign-on for customers. | [NOT IN PLACE] |
docs/soc2-readiness.md |
5. Controls on changes to customer resources
| Measure | Status | Source |
|---|---|---|
| Commands are rendered from fixed templates using identifiers that must match a strict pattern. The model supplies no command text. | In code | remediation/engine.py, remediation/templates/ |
| Risk tiers are fixed in code. High-risk actions are never executable and the write role has no permission for them. | In code | remediation/engine.py, cloudformation/cost-agent-remediator.yaml |
| Approval by an identified caller, recorded with the commands. At execution the plan is rendered again and must match the approved hash and commands. Approvals expire after 72 hours. | In code | remediation/approvals.py |
| Run-time pre-check against live AWS. Keep tags and the allow-list are honoured. Dry run where the API supports it. | In code | remediation/prechecks.py, remediation/approvals.py |
| Backup snapshot before a volume is deleted. Explicit acknowledgement for medium-risk actions with no backup step. | In code | remediation/templates/unattached_volume.json.j2, remediation/approvals.py |
| Terraform-managed resources are changed only by a pull request. Spendsaw does not run Terraform or merge. | In code | iac/pr.py, iac/github_app.py |
6. Controls on the model
| Measure | Status | Source |
|---|---|---|
| The model can call six typed, read-only tools that return metadata, metrics and cost totals. There is no general AWS tool. | In code | ai/tools.py |
| Text from AWS accounts is flattened, stripped of control characters, truncated to 200 characters per field and wrapped in a delimited block declared to be data. | In code | security/sanitize.py |
| Commands and code blocks in model output are removed. Finding ids the model invents are dropped. | In code | ai/bedrock_client.py |
| Live prompt-injection test. | [NOT YET RUN] |
Build plan, Phase 0 gate |
7. Logging, monitoring and resilience
| Measure | Status | Source |
|---|---|---|
| Every request, approval, refusal, step and failure is appended to the action record. | In code | remediation/approvals.py |
| Application, workflow and API access logs with 30-day default retention. | Designed | infra/terraform/modules/scanner/, infra/terraform/modules/api/main.tf |
| Alarms for scan failures, the dead-letter queue, function errors and per-tenant cost. | Designed | infra/terraform/modules/observability/main.tf |
| Point-in-time recovery on customer tables, with a deletion-protection setting. | Designed | infra/terraform/modules/tables/main.tf, infra/terraform/envs/tooling/variables.tf |
| Dependencies pinned. Automated tests and lint in the build pipeline. | In code | requirements.txt, Jenkinsfile |
8. Not in place at the date of this draft
Stated so that Customer can assess the risk for itself:
- No SOC 2 report, ISO certification or other attestation. No independent penetration test.
- No written information security policy, incident response plan or business continuity plan.
- No security alerting, and no audit trail or threat detection service defined for Spendsaw's own AWS account.
- No defined retention schedule or tenant deletion procedure.
- No staff access policy, background checks or security training record.
Annex III. Sub-processors
| Sub-processor | Service | Customer Personal Data handled | Location |
|---|---|---|---|
| Amazon Web Services, Inc. | Hosting in Spendsaw's AWS account: compute, database, secrets, logs, sign-in. Model inference through Amazon Bedrock. | All categories in Annex I | [HOSTING REGION]. The default in the code is us-east-1, United States. The example configuration's inference profile can route model requests to us-east-1, us-east-2 or us-west-2. |
| Slack Technologies, LLC, only if Customer installs the Slack app | Delivery of digests, alerts and approval buttons to the channel Customer chooses | Finding titles, amounts, account names, regions, commands, approver identity | As set by Customer's agreement with Slack |
| GitHub, Inc., only if Customer installs the GitHub App | Hosting the branch and pull request the app opens | Resource ids, account ids, regions, savings, the Terraform change | As set by Customer's agreement with GitHub |
| Stripe, Inc. | Billing | None. Stripe handles Customer's account and billing data, for which Spendsaw is a controller. It is listed for completeness. | United States and other countries |