Privacy policy (draft)

Effective date: [EFFECTIVE DATE]

This policy explains what personal data Spendsaw handles, why, and what you can do about it. Spendsaw is a 45Squared venture, operated by [LEGAL ENTITY NAME], a [ENTITY TYPE] formed in [STATE OF FORMATION], of [REGISTERED ADDRESS] ("Spendsaw", "we", "us").

1. Two roles

Spendsaw handles personal data in two different roles. Which one applies decides who answers your request.

1.1 Spendsaw as controller. We decide how and why we use the data about the people who deal with us directly: people who visit spendsaw.com, create a Spendsaw account, pay for a plan, approve changes, or write to us. This policy covers that data.

1.2 Spendsaw as processor. When a customer connects an AWS account, the Hosted Service collects metadata from it. That metadata belongs to the customer and can contain small amounts of personal data, such as a person's name in a resource tag. We process it only on the customer's instructions, as a processor (a "service provider" under California law). The Data Processing Addendum (the "DPA") governs that processing. Section 4 of this policy describes it so that the picture is complete. If your personal data is in a customer's AWS metadata, contact that customer first. We will help them respond.

1.3 The free local software. The spendsaw-mcp server runs on your own machine with your own AWS credentials. It has no hosted backend and sends nothing to Spendsaw. We receive no data from it. Its results go to the AI assistant you connect it to, so that assistant's provider sees them. Its cache stays on your machine, for 6 hours by default.

2. Data we handle as controller

2.1 Account and contact details.

Your email address, which is your sign-in name for the Hosted Service.
Your name and company name, if you give them.
What you write to us by email.

2.2 Sign-in and authentication data.

In the hosted design, sign-in is handled by Amazon Cognito in our AWS account. Cognito holds your email address, a hashed password, and a one-time-code secret if you turn on multi-factor authentication. We do not see your password.
The identifiers in your sign-in token: a user id, your email or username, and the group that links you to your company's Spendsaw account.
For API access: API client ids and the tokens or client credentials issued to you.

2.3 Billing data.

A Stripe customer id, subscription id and subscription item id.
Your plan, subscription status, quantity of connected AWS accounts, trial end date and current period end date.
The email address you give at checkout, which we pass to Stripe to create your customer record.
We do not receive or store your card number. You enter card details on Stripe's checkout page and Stripe holds them.

2.4 Approver identities. When someone requests, approves, rejects, snoozes or runs a change, the action record stores who did it, when, and the exact commands. The identity stored is:

from Slack: the Slack workspace id, the Slack user id and the Slack username, in the form slack:<workspace id>:<user id> (<username>);
from the console or API: the email address, username or user id in the sign-in token, or the name of the API client.

Each entry in the savings ledger also stores who approved the change it records.

2.5 Slack and GitHub installation data. If your company installs the Slack app: the workspace id, the channel chosen for the digest, and the list of Slack user ids allowed to approve. If your company installs the GitHub App: the installation id and the names of the repositories linked.

2.6 Console questions. If you ask a question in the console chat, we store the question, the answer and recent turns of the conversation, and send them to the model (section 6).

2.7 Server logs. Our application, workflow and API access logs record requests to the Hosted Service. In the hosted design, the API access log format records a request id, the time, the route, the response status, the response time, the API client id and any authorisation error. It does not record the caller's IP address. [API ACCESS LOGS: owner to re-confirm the format at deployment, and whether any other layer in front of the API, such as a content delivery network or a firewall, keeps IP addresses.] Application logs record a Slack user id when someone who is not on the approver list tries to approve.

2.8 Website visits. spendsaw.com is a static website. It has no forms, no accounts and no analytics. See section 9 for cookies and for the fonts it loads from Google. The company that hosts the website will keep standard web server logs, which include your IP address: [WEBSITE HOST: not yet chosen. Name the host and its log retention here.]

2.9 What we do not collect as controller. We do not buy personal data, we do not build advertising profiles, and no analytics, advertising or email-marketing tool is used by the website or the Hosted Service at the date of this draft.

3. Why we use controller data, and our lawful bases

For readers in the European Economic Area, the United Kingdom and Switzerland, the GDPR and UK GDPR require a lawful basis for each use.

Purpose	Data	Lawful basis
Creating your account and signing you in	Account, sign-in	Performance of our contract with you or your company (GDPR Art. 6(1)(b)), or our legitimate interest in providing the service your employer bought (Art. 6(1)(f))
Taking payment and managing your subscription	Billing	Performance of contract (Art. 6(1)(b)); legal obligation for tax and accounting records (Art. 6(1)(c))
Recording who approved each change	Approver identities	Legitimate interests (Art. 6(1)(f)): we and the customer both need an accurate record of who authorised a change to cloud infrastructure
Delivering digests and opening pull requests	Slack and GitHub installation data	Performance of contract (Art. 6(1)(b)) or legitimate interests (Art. 6(1)(f))
Answering console questions	Console questions	Performance of contract (Art. 6(1)(b)) or legitimate interests (Art. 6(1)(f))
Keeping the service secure and finding faults	Logs, sign-in data	Legitimate interests (Art. 6(1)(f)) in a secure and reliable service
Replying when you write to us	Contact details	Legitimate interests (Art. 6(1)(f)) in answering you
Meeting legal duties and handling disputes	Any of the above, as needed	Legal obligation (Art. 6(1)(c)); legitimate interests (Art. 6(1)(f))

We do not make decisions about people by automated means that have a legal or similarly significant effect on them. The model ranks AWS resources, not people.

4. Data we handle as processor

This section describes customer data. The DPA, not this policy, sets the rules for it.

4.1 What the Hosted Service reads from a connected AWS account.

Account identifiers. AWS account ids and account names.
Account root email addresses. The AWS Organizations ListAccounts call, which the Hosted Service can use to discover the accounts in an organisation, returns the root email address of each account as part of AWS's response. [ACCOUNT EMAIL HANDLING: see the note below. Draft statement, to be confirmed against the code at publication: Spendsaw does not keep, store, display or send that email address anywhere.]
Resource metadata. Resource ARNs, ids, names, tags and short descriptions, and configuration state such as size, type, attachment, age and architecture.
Metrics. CloudWatch metric statistics from AWS service namespaces.
Cost data. Cost Explorer totals, and billed cost per resource if the customer connects the Cost and Usage Report.
AWS's own recommendations for the account.
Amazon Bedrock usage. Tokens per model, and which principals called or can call Bedrock. To work this out the scanner reads CloudTrail management events for Bedrock and keeps the caller's ARN, the last part of that ARN as the principal name, the type of client and the event name. For a person signed in through single sign-on, the last part of the ARN is often their username or email address.

4.2 Where personal data can appear in it. The Hosted Service does not look for personal data, but AWS metadata can contain some:

a person's name or email address in a resource name, a tag or a description;
IAM user names, role names and role session names in ARNs;
an AWS account name that is a person's name.

4.3 What the Hosted Service does not read. The read-only role that customers deploy carries an explicit deny, in IAM, on reading:

S3 object contents;
DynamoDB items;
secret values and parameter values;
log events;
Lambda function code, queue messages, stream records, container images and repository contents;
Amazon Bedrock agent memory and knowledge-base retrieval.

The deny list names specific data-plane actions. It is not a deny on every data API in every AWS service. Two metadata calls (lambda:GetFunctionConfiguration and ecs:DescribeTaskDefinition) return environment variables in AWS's response. The scanner does not read or store them.

4.4 The one exception: Terraform state. If a customer deploys the separate, opt-in state reader role and names a state bucket, the Hosted Service reads Terraform state files from that bucket. State files can hold secrets. The parser keeps only, for each managed resource: its address, type, name, module, index, provider, id and arn, and the bucket and key it was found in. Every other attribute is discarded before the parser returns. It is not stored, not logged and not sent to the model.

4.5 Linked repositories. If a customer installs the GitHub App, the Hosted Service reads Terraform files in the linked repositories to find the block for a resource, and writes a branch and a pull request there.

5.1 Service providers. We use these providers. Each processes data only to provide its service to us.

Provider	What it does for us	Data it handles
Amazon Web Services	Hosting for the Hosted Service, in our own AWS account: compute, database, sign-in (Amazon Cognito), secrets, logs. Model inference through Amazon Bedrock.	All data in sections 2.1 to 2.7 and section 4
Stripe	Checkout, card processing, invoices and the billing portal	Billing data in section 2.3, and the card and billing details you give Stripe directly
Slack, only if your company installs the Slack app	Delivers the digest and the approve and snooze buttons to the channel your company chooses	Finding titles, amounts, account names, regions, the commands for the top actions, and the approver's identity in the result message
GitHub, only if your company installs the GitHub App	Hosts the branch and pull request the app opens	Resource ids, account ids, regions, the estimated saving and the Terraform change, in the repository your company links

No analytics, advertising or email-marketing provider is used.

5.2 Google Fonts. The website loads its typefaces from Google Fonts. See section 9.3.

5.3 Other disclosures. We may disclose personal data: (a) to professional advisers, (b) to a buyer or successor if the business is sold or reorganised, under confidentiality, and (c) where the law, a court or a regulator requires it.

5.4 No sale. We do not sell personal data and we do not share it for advertising.

6. What is sent to the model

The Hosted Service uses a model on Amazon Bedrock to explain findings in plain English, and may use it to rank them. The model runs in our AWS account, not the customer's. The default model in the code is Amazon Nova Lite. [MODEL: the final model is an open decision in the build plan.]

For ranking and explaining: up to 60 finding rows (id, title, waste type, account, region, saving, cost source, confidence, risk, evidence), a cost summary, and Bedrock usage by model and caller.
For chat: the customer's account ids and names, cost totals, the question asked, recent conversation turns, and what six fixed tools return. Those tools return metadata, metrics and cost totals only.
Resource names, tags and descriptions are cleaned and truncated to 200 characters per field before they are included.
Each request to the model carries the customer's tenant id as metadata.

[BEDROCK INVOCATION LOGGING: not yet defined. If logging is turned on, prompts and responses would be stored in our AWS account. State whether it is on, and the retention period, before publishing.]

[MODEL TRAINING: counsel and owner to confirm against the current AWS service terms before stating how AWS handles prompts and responses. Spendsaw itself does not use customer data to train models.]

7. Where data is processed

7.1 Hosting region. [HOSTING REGION: not yet defined.] The default region in the code is us-east-1, in the United States. The example hosted configuration uses a United States cross-region inference profile, which can route a model request to us-east-1, us-east-2 or us-west-2.

7.2 No residency commitment. We do not commit to keeping data in any particular country or region. [DATA RESIDENCY: owner decision.]

7.3 Transfers from the EEA, UK and Switzerland. If you are in the EEA, the UK or Switzerland, your personal data will be transferred to and processed in [COUNTRY OF HOSTING, expected to be the United States]. For customer data, the DPA incorporates the European Commission's standard contractual clauses and the UK addendum. For controller data, we rely on [TRANSFER MECHANISM FOR CONTROLLER DATA: counsel to specify.] Stripe, Slack and GitHub process data in the United States and other countries under their own transfer arrangements.

8. How long we keep data

This table states only what the code and infrastructure set today. Where no period has been set, the entry is a bracketed placeholder for the owner to decide. It matches the "Data retention" section of the trust page.

Data	Retention
Findings	Replaced on each scan. A finding that a successful scan of its account and region no longer sees is deleted. No time-based expiry is set.
Approval and action records, including approver identities	No expiry is set. `[RETENTION: APPROVAL AND ACTION RECORDS, not yet defined]`
Savings ledger, including who approved each entry	No expiry is set. `[RETENTION: SAVINGS LEDGER, not yet defined]`
Account record and the ExternalId secret	Kept while the customer account exists. `[DELETION ON OFFBOARDING, not yet defined]`
Subscription state	No expiry is set. `[RETENTION: BILLING RECORDS, not yet defined. Tax and accounting law will set a minimum.]`
Ids of processed payment-provider webhook events	7 days
Sign-in accounts (Amazon Cognito)	`[RETENTION: SIGN-IN ACCOUNTS, not yet defined]`
Console chat conversations (self-hosted dashboard)	7 days, and at most the last 40 messages
Application, workflow and API access logs	30 days by default
Failed scan messages (dead-letter queue)	14 days
Database backups	Point-in-time recovery is enabled on the customer tables. `[BACKUP RECOVERY WINDOW, not set in the infrastructure code]`
Analysis history (self-hosted dashboard)	Files on the deployment's own disk. No expiry is set.
Price cache	7 days. Public AWS list prices, not personal data.
Local MCP server cache	6 hours by default, on the user's own machine
Backup snapshots taken before a delete	Created in the customer's AWS account. They stay until the customer deletes them.
Amazon Bedrock invocation logs	`[RETENTION: BEDROCK INVOCATION LOGS, not yet defined]`
Email correspondence	`[RETENTION: CORRESPONDENCE, not yet defined]`

9. Cookies and similar technologies

9.1 The console. The console sets one cookie, a session cookie. It is needed for the console to work and it links your browser to your console session, including your chat conversation. It is marked HttpOnly and SameSite=Lax. It is not used for advertising or analytics.

9.2 The website. spendsaw.com sets no cookies. If you use the light and dark toggle, your choice is saved in your browser's local storage under the name spendsaw-theme. It stays in your browser and is not sent to us.

9.3 Google Fonts. The website's style sheets load two typefaces from Google Fonts. To fetch them, your browser connects to Google's servers, which means Google receives your IP address, your browser's user-agent and the address of the page you are on. We do not receive that data and we do not control what Google does with it. Google's privacy policy applies. [GOOGLE FONTS: owner decision. Hosting the font files on spendsaw.com would remove this disclosure, and this paragraph with it.]

9.4 No advertising or tracking technologies. We use no advertising cookies, no analytics cookies, no tracking pixels and no cross-site tracking. Because there is nothing to opt out of, the website does not respond differently to browser "Do Not Track" or Global Privacy Control signals.

10. Security

These measures exist in the code and infrastructure definitions today. The hosted infrastructure has been validated offline and has not yet been deployed, so the measures marked "designed" are not yet operating.

Access to customer AWS accounts is only through IAM roles the customer deploys, each of which requires a per-customer ExternalId. We hold no long-lived AWS access keys for customer accounts. Sessions last at most 3600 seconds, and 900 seconds for the write role.
Reading and writing are separate roles. The read-only role denies data-plane reads. The write role is opt-in and limited to the low and medium risk actions.
Tenant isolation (designed). Every customer table is keyed by tenant id, and each worker runs in a session whose IAM policy allows it to read and write only its own tenant's rows.
Encryption at rest (designed). Server-side encryption is enabled on the database tables, the failed-scan queue and the bucket that holds the role templates.
Encryption in transit. The Hosted Service calls AWS, Stripe, Slack and GitHub over HTTPS. [TLS FOR THE HOSTED API AND CONSOLE: configuration not yet defined.]
Sign-in (designed). Passwords of at least 14 characters, optional multi-factor authentication with a one-time code, invite-only accounts, access tokens that expire after 60 minutes.
Signed webhooks. Requests from Stripe and Slack are accepted only with a valid signature and a recent timestamp.
Limits on the model. The model can call six fixed read-only tools and has no general access to AWS. Text from AWS accounts is cleaned and marked as untrusted before it reaches the model.
Records. Every approval and action is written to an action record.

What is not in place. There is no SOC 2 report or other certification, no independent penetration test, no written incident response plan, and multi-factor authentication is optional, not required. No system is perfectly secure. If you believe you have found a security problem, write to [security@spendsaw.com].

11. Your rights

11.1 Everyone. You can ask us what personal data we hold about you, ask us to correct it, or ask us to delete it. Write to [privacy@spendsaw.com]. We will answer within the time the law requires and, where no law sets one, within 30 days. We may need to confirm who you are first.

11.2 If your data is in a customer's account. If your personal data reached us because it is in a customer's AWS metadata or because you are an approver on a customer's account, we will pass your request to that customer and help them answer it.

11.3 EEA, UK and Switzerland. Under the GDPR and UK GDPR you have the right to: access your personal data; have it corrected; have it erased; restrict its processing; object to processing based on legitimate interests; receive the data you gave us in a portable format; and withdraw consent where we rely on consent. You also have the right to complain to your data protection authority. In the UK that is the Information Commissioner's Office. We ask that you contact us first so we can try to resolve it.

[EU REPRESENTATIVE: counsel to advise whether GDPR Art. 27 requires one, and name it here.] [UK REPRESENTATIVE: counsel to advise whether UK GDPR Art. 27 requires one, and name it here.] [DATA PROTECTION OFFICER: counsel to advise whether one is required. None is appointed.]

11.4 California. This section applies to California residents and adds to the rest of this policy. It is written for the California Consumer Privacy Act as amended by the California Privacy Rights Act (the "CCPA").

Categories we collect. Identifiers (name, email address, user ids, Slack user id, IP address in logs); commercial information (plan and subscription records); internet or network activity (logs of your use of the Hosted Service); and professional information (your company and your role as an approver). Sections 2 and 4 give the detail and the sources.
Purposes. The purposes in section 3.
Disclosures for a business purpose. We disclose each category to the service providers in section 5.1 for those purposes.
No sale or sharing. We do not sell personal information. We do not share personal information for cross-context behavioural advertising. We have not done either in the past 12 months.
Sensitive personal information. We do not use or disclose sensitive personal information for purposes other than providing the Hosted Service. Sign-in credentials are handled by Amazon Cognito.
Your rights. You have the right to know what personal information we have collected about you, to have it deleted, to have it corrected, and not to be discriminated against for using these rights. Because we do not sell or share personal information, there is nothing to opt out of.
How to use them. Write to [privacy@spendsaw.com]. You may use an authorised agent. We will ask the agent for proof of your permission.
Retention. Section 8.

12. Children

The Services are for people who operate AWS accounts for a business. They are not directed to children, and we do not knowingly collect personal data from anyone under [MINIMUM AGE: 18, or 16 if counsel prefers to follow the GDPR default]. If you believe a child has given us personal data, write to [privacy@spendsaw.com] and we will delete it.

13. Changes to this policy

We will post any change on this page and change the effective date. For a change that materially affects how we use personal data, we will tell account holders by email or in the console at least [PRIVACY CHANGE NOTICE DAYS] days before it takes effect.

14. Contact

[LEGAL ENTITY NAME] [REGISTERED ADDRESS] Privacy questions and requests: [privacy@spendsaw.com] Security reports: [security@spendsaw.com] General: hello@spendsaw.com